B2B コラボレーションの招待の利用
適用対象: 従業員テナント 外部テナント (詳細はこちら)
この記事では、ゲスト ユーザーがリソースにアクセスできる方法と実行する同意プロセスについて説明します。 招待メールをゲストに送信する場合、その招待には、ゲストがアプリまたはポータルにアクセスするために利用できるリンクを含めます。 招待メールは、ゲストがリソースにアクセスできる方法の 1 つにすぎません。 別の方法として、ゲストをディレクトリに追加し、共有したいポータルまたはアプリへの直接リンクを提供することができます。 使用する方法に関係なく、ゲストには初回の同意プロセスが示されます。 このプロセスにより、ゲストは確実にプライバシー条項に同意し、設定された利用規約を承諾することになります。
ゲスト ユーザーをディレクトリに追加すると、そのゲスト ユーザーのアカウントは同意状態 (PowerShell で表示可能) になります。これは、最初は PendingAcceptance に設定されます。 ゲストが招待を受け入れ、プライバシー ポリシーと利用規約に同意するまで、この設定は維持されます。 その後、同意の状態が承認済みに変わり、同意ページはゲストに表示されなくなります。
重要
- 2021 年 7 月 12 日以降、Microsoft Entra B2B のお客様が、カスタムまたは基幹業務アプリケーションのセルフサービス サインアップで使用するために新しい Google の統合をセットアップした場合、認証がシステム Web ビューに移動されるまで、Google ID を使用した認証が機能しなくなります。 詳細情報 を参照してください。
- 2021 年の 9 月 30 日より、Google は埋め込みの Web ビューのサインイン サポートを廃止します。 アプリで埋め込み Web ビューを使用してユーザーを認証していて、Google フェデレーションを Azure AD B2C、Microsoft Entra B2B (外部ユーザーの招待用)、またはセルフサービス サインアップで使用している場合、Google Gmail ユーザーが認証されなくなります。 詳細情報 を参照してください。
- すべての新しいテナントと、明示的に無効にしていない既存のテナントに対して、電子メール ワンタイム パスコード機能が既定で有効になりました。 この機能をオフにすると、フォールバック認証方法は、Microsoft アカウントの作成を招待者に求める方法です。
共通のエンドポイントを使用した引き換えプロセスとサインイン
ゲスト ユーザーは、https://myapps.microsoft.com
のような共通のエンドポイント (URL) を介して、マルチテナント アプリまたは Microsoft のファーストパーティ アプリにサインインできるようになりました。 これまで、ゲスト ユーザーは認証のために共通 URL によって、リソース テナントではなくホーム テナントにリダイレクトされていたため、テナント固有のリンク (例: https://myapps.microsoft.com/?tenantid=<tenant id>
) が必要でした。 現在、ゲスト ユーザーはアプリケーションの共通 URL にアクセスして、 [サインイン オプション] を選択し、 [Sign in to an organization](組織にサインイン) を選択できます。 次に、ユーザーは組織のドメイン名を入力します。
その後、ユーザーはテナント固有のエンドポイントにリダイレクトされます。このエンドポイントでは、メール アドレスを使用してサインインするか、構成済みの ID プロバイダーを選択することができます。
直接リンクによる引き換えプロセス
招待メールまたはアプリケーションの共通 URL の代わりに、アプリまたはポータルへの直接リンクをゲストに提供することができます。 まず、Microsoft Entra 管理センターまたは PowerShell を介して、ゲスト ユーザーをディレクトリに追加する必要があります。 その後、直接サインオン リンクを含む、ユーザーにアプリケーションをデプロイするためのカスタマイズ可能な方法のいずれかを使用できます。 ゲストには、招待メールではなく直接リンクを使用する際にも、初回の同意エクスペリエンスが示されます。
Note
直接リンクはテナント固有です。 つまり、共有アプリが配置されている、テナントでゲストを認証できるように、テナント ID または確認済みドメインが含まれています。 テナント コンテキストを含む直接リンクの例をいくつか以下に示します。
- アプリ アクセス パネル:
https://myapps.microsoft.com/?tenantid=<tenant id>
- 確認済みドメインのアプリ アクセス パネル:
https://myapps.microsoft.com/<;verified domain>
- Microsoft Entra 管理センター:
https://entra.microsoft.com/<tenant id>
- 個々のアプリ: 直接サインオン リンクの使用方法を参照してください
直接リンク経由の招待メールが推奨されるケースがいくつかあります。 このような特殊なケースが組織にとって重要な場合は、引き続き招待メールを送信する方法を使用してユーザーを招待することをお勧めします。
- 連絡先オブジェクト (Outlook の連絡先オブジェクトなど) と競合するため、招待されたユーザー オブジェクトにメール アドレスを持っていないことがあります。 この場合、ユーザーは招待メールの引き換え URL を選択する必要があります。
- ユーザーは、招待されたメール アドレスの別名でサインインすることができます (エイリアスは、メール アカウントに関連付けられた別のメール アドレスです)。この場合、ユーザーは招待メールの引き換え URL を選択する必要があります。
招待メールによる引き換えプロセス
Microsoft Entra 管理センターを使用してディレクトリにゲスト ユーザーを追加すると、そのプロセスで招待メールがゲストに送信されます。 ゲスト ユーザーをディレクトリに追加するために PowerShell を使用する際に、招待メールを送信するように選択することもできます。 以下は、メールのリンクを利用する場合のゲストのエクスペリエンスの説明です。
- ゲストは、Microsoft Invitations から送信される招待メールを受け取ります。
- ゲストは、電子メールで [招待の承諾] を選択します。
- ゲストは、自分の資格情報を使用してディレクトリにサインインします。 ゲストがディレクトリにフェデレーションできるアカウントを持っておらず、電子メール ワンタイム パスコード (OTP) 機能が有効になっていない場合、ゲストは個人用 MSA を作成するように求められます。 詳細については、「招待の引き換えフロー」を参照してください。
- ゲストには、以下に説明されている同意エクスペリエンスが示されます。
連絡先オブジェクトの競合による引き換えプロセスの制限
招待された外部ゲスト ユーザーのメール アドレスが既存の連絡先オブジェクトと競合しているために、ゲスト ユーザーが proxyAddress なしで作成される場合があります。 これは、ゲスト ユーザーが SAML/WS-Fed IdP、MSA、Google フェデレーション、または電子メール ワンタイム パスコード アカウントを使用して、直接リンクから招待を引き換えることができないという、既知の制限です。
ただし、次のシナリオは引き続き機能します。
- SAML/WS-Fed IdP、電子メール ワンタイム パスコード、および Google フェデレーション アカウントを使用して、招待メールの引き換えリンクから招待を引き換える。
- SAML/WS-Fed IdP、メールのワンタイム パスコード、および Google フェデレーション アカウントを使用して、引き換えプロセス後にアプリケーションにもう一度サインインする。
連絡先オブジェクトの競合が原因で招待を引き換えることができないユーザーのブロックを解除するには、これらの手順に従います。
- 競合する連絡先オブジェクトを削除します。
- Microsoft Entra 管理センターでゲスト ユーザーを削除します (ユーザーの "招待が受け入れられました" プロパティが保留状態である必要があります)。
- ゲスト ユーザーを再度招待します。
- ユーザーが招待を引き換えるまで待ちます。
- ユーザーの連絡先の電子メールを、Exchange と、それらが含まれている必要がある DL に再度追加します。
招待の引き換えフロー
ユーザーが招待メールの [招待を承諾] リンクを選ぶと、Microsoft Entra ID では、以下に示す既定の引き換え順序に基づいて招待を自動的に引き換えます。
Microsoft Entra ID は、ユーザーベースの検出を実行して、ユーザーがマネージド Microsoft Entra テナントに既に存在するかどうかを判断します。 (管理されていない Azure AD アカウントは引き換えフローに使用できなくなりました。) ユーザーのユーザー プリンシパル名 (UPN) が既存の Microsoft Entra アカウントと個人用 MSA の両方と一致する場合、ユーザーは引き換えに使用するアカウントを選択するように求められます。
管理者が SAML/WS-Fed IdP フェデレーションを有効にしている場合、Microsoft Entra ID では、ユーザーのドメインサフィックスと構成されている SAML/WS-Fed ID プロバイダーのドメインが一致するかどうかを確認し、あらかじめ構成されている ID プロバイダーにユーザーをリダイレクトします。
管理者が Google フェデレーションを有効にしている場合、Microsoft Entra ID では、ユーザーのドメイン サフィックスが gmail.com か googlemail.com であるかどうかが確認され、ユーザーが Google にリダイレクトされます。
引き換えプロセスでは、ユーザーに個人用の MSA が既に与えられているかどうかが確認されます。 ユーザーに既存の MSA がある場合は、既存の MSA でサインインします。
ユーザーのホーム ディレクトリが確認されると、ユーザーはサインインするため、それに対応する ID プロバイダーの元に送られます。
ホーム ディレクトリが見つからず、ゲストの電子メール ワンタイム パスコード機能が "有効になっている" 場合、招待メール経由でユーザーにパスコードが送信されます。 ユーザーはこのパスコードを取得し、Microsoft Entra サインイン ページで入力します。
ホーム ディレクトリが見つからず、ゲストの電子メール ワンタイム パスコードが "無効になっている" 場合、ユーザーは招待メールでコンシューマー MSA を作成するように求められます。 Microsoft Entra ID で検証されていないドメインで、仕事用メールを使用して MSA を作成することがサポートされています。
正しい ID プロバイダーに対して認証を行った後、同意エクスペリエンスを完了するため、ユーザーは Azure AD にリダイレクトされます。
構成可能な引き換え
構成可能な引き換えでは、招待状を引き換えるときにゲストに提示される ID プロバイダーの順序をカスタマイズできます。 ゲストが [招待を承諾] リンクを選ぶと、Microsoft Entra ID は、既定の順序に基づいて招待を自動的に引き換えます。 これをオーバーライドするには、テナント間アクセス設定で ID プロバイダーの引き換え順序を変更します。
ゲストの同意エクスペリエンス
ゲストが初めてパートナー組織のリソースにサインインすると、以下の同意エクスペリエンスが表示されます。 これらの同意ページは、ゲストがサインインした後のみ表示され、ユーザーが既に同意している場合は表示されません。
ゲストは、招待元の組織のプライバシーに関する声明について説明されている [アクセス許可の確認] ページを確認します。 ユーザーは、操作を続行するために、招待元の組織のプライバシー ポリシーに従って情報を使用することに同意する必要があります。
この同意プロンプトに同意すると、アカウントの特定の要素が共有されることを確認したことになります。 これには、名前、写真、電子メール アドレスのほか、他の組織がアカウントをより適切に管理し、組織間のエクスペリエンスを向上させるために使用できるディレクトリ識別子が含まれます。
Note
テナント管理者が組織のプライバシーに関する声明にリンクする方法については、「方法: Microsoft Entra ID で組織のプライバシー情報を追加する」を参照してください。
利用規約が構成されている場合、ゲストはその利用規約を開き、確認してから、 [同意] を選択します。
[外部 ID]>[使用条件] で使用条件を構成できます。
特に指定されていない限り、ゲストはアプリ アクセス パネルにリダイレクトされます。そこには、ゲストがアクセスできるアプリケーションがリスト表示されています。
ディレクトリでは、ゲストの [招待が受け入れられました] の値が [はい] に変わります。 MSA が作成された場合、ゲストの [ソース] には Microsoft アカウントが示されます。 ゲスト ユーザー アカウントのプロパティの詳細については、Microsoft Entra B2B コラボレーション ユーザーのプロパティを参照してください。 アプリケーションへのアクセス中に管理者の同意を要求するエラーが表示される場合は、アプリに管理者の同意を付与する方法に関するページを参照してください。
自動引き換えプロセスの設定
ユーザーが B2B コラボレーションの別のテナントに追加されたときに同意プロンプトを受け入れる必要がないように、自動的に招待を利用することができます。 構成すると、ユーザーからの操作は必要ないという内容の通知メールが B2B コラボレーション ユーザーに送信されます。 通知メールはユーザーに直接届きます。また、メールを受信するためにテナントにアクセスする必要はありません。
自動的に招待を利用する方法の詳細については、テナント間アクセスの概要に関する記事と「B2B コラボレーションのためにテナント間アクセス設定を構成する」を参照してください。