外部 ID の認証と条件付きアクセス

適用対象: 従業員テナント 外部テナント (詳細情報)

外部ユーザーが組織内のリソースにアクセスするときの認証フローは、コラボレーション方法 (B2B コラボレーションまたは B2B 直接接続)、ユーザーの ID プロバイダー (外部の Microsoft Entra テナント、ソーシャル ID プロバイダーなど)、条件付きアクセス ポリシー、およびユーザーのホーム テナントとテナント ホスティング リソースの両方で構成されたテナント間アクセス設定によって決まります。

この記事では、組織内のリソースにアクセスしている外部ユーザーの認証フローについて説明します。 組織は、外部ユーザーに対して複数の条件付きアクセス ポリシーを適用できます。これは、組織のフルタイムの従業員とメンバーに対して有効にしたのと同じ方法で、テナント、アプリ、または個々のユーザー レベルで適用できます。

外部 Microsoft Entra ユーザーの認証フロー

次の図は、Microsoft Entra 組織がリソースを他の Microsoft Entra 組織からのユーザーと共有する場合の認証フローを示しています。 この図は、テナント間のアクセス設定が多要素認証などの条件付きアクセス ポリシーと連携して、ユーザーがリソースにアクセスできるかどうかを判断する方法を示しています。 このフローは、手順 6 で示されている場合を除き、B2B コラボレーションと B2B 直接接続の両方に適用されます。

詳細については、「外部ユーザーの条件付きアクセス」セクションを参照してください。

Azure AD 外部ユーザー以外の認証フロー

Microsoft Entra 組織が Microsoft Entra ID 以外の ID プロバイダーを使用してリソースを外部ユーザーと共有する場合、認証フローは、ユーザーが ID プロバイダーまたは電子メール ワンタイム パスコード認証を使用して認証を行うかどうかによって異なります。 どちらの場合でも、リソース テナントは、使用する認証方法を識別し、ユーザーを ID プロバイダーにリダイレクトするか、ワンタイム パスコードを発行します。

例 1: Azure AD 外部ユーザー以外のユーザーの認証フローおよびトークン

次の図は、外部ユーザーが Google、Facebook、フェデレーション SAML/WS-Fed ID プロバイダーなど、Azure AD 以外の ID プロバイダーのアカウントでサインインする場合の認証フローを示しています。

例 2: ワンタイム パスコード ユーザーの認証フローとトークン

次の図は、電子メール ワンタイム パスコード認証が有効で、外部ユーザーが Microsoft Entra ID、Microsoft アカウント (MSA)、ソーシャル ID プロバイダーなどの他の方法では認証されない場合のフローを示しています。

外部ユーザーの条件付きアクセス

組織は、組織のフルタイムの従業員とメンバーに対して有効にしたのと同じ方法で、外部の B2B コラボレーションおよび B2B 直接接続ユーザーに条件付きアクセス ポリシーを適用できます。 テナント間アクセス設定を導入すると、外部の Microsoft Entra 組織からの MFA とデバイス要求を信頼することもできます。 このセクションでは、組織外のユーザーに条件付きアクセスを適用する際の重要な考慮事項について説明します。

外部ユーザーの種類への条件付きアクセス ポリシーの割り当て

条件付きアクセス ポリシーを構成する際に、ポリシーを適用する外部ユーザーの種類をきめ細かく制御できます。 外部ユーザーは、認証方法 (内部または外部) および組織との関係 (ゲストまたはメンバー) に基づいて分類されます。

• B2B コラボレーション ゲスト ユーザー - 一般的にゲストと見なされるほとんどのユーザーは、このカテゴリに分類されます。 この B2B コラボレーション ユーザーは、外部 Microsoft Entra 組織または外部 ID プロバイダー (ソーシャル ID など) にアカウントを持ち、組織内でゲストレベルのアクセス許可を持っています。 Microsoft Entra ディレクトリに作成されるユーザー オブジェクトの UserType は "ゲスト" です。 このカテゴリには、招待された、およびセルフサービス サインアップを使用した、B2B コラボレーション ユーザーが含まれます。
• B2B コラボレーション メンバー ユーザー - この B2B コラボレーション ユーザーは、外部 Microsoft Entra 組織または外部 ID プロバイダー (ソーシャル ID など) にアカウントを持ち、組織内のリソースに対するメンバーレベルのアクセス権を持っています。 このシナリオがよく見られるのは、複数のテナントで構成される組織において、ユーザーが大規模な組織の一部と見なされ、組織の他のテナント内のリソースに対するメンバーレベルのアクセス許可を必要とする場合です。 リソース Microsoft Entra ディレクトリに作成されるユーザー オブジェクトの UserType は "メンバー" です。
• B2B 直接接続ユーザー - 特定の Microsoft アプリケーション (現在、Microsoft Teams Connect 共有チャネル) へのシングル サインオン アクセスを許可する別の Microsoft Entra 組織との相互の双方向接続である B2B 直接接続を介してリソースにアクセスできる外部ユーザー。 B2B 直接接続ユーザーは、Microsoft Entra 組織にプレゼンスを持たず、代わりにアプリケーション内から (Teams 共有チャネル所有者によるなどして) 管理されます。
• ローカル ゲスト ユーザー - ローカル ゲスト ユーザーには、ディレクトリ内で管理される資格情報があります。 Microsoft Entra B2B コラボレーションが利用できるようになる前は、販売代理店、仕入先、製造元、およびその他のユーザーと共同作業を行うには、これらのユーザーの内部資格情報を設定し、ユーザー オブジェクトの UserType を "ゲスト" に設定することで、ゲストとして指定するのが一般的でした。
• サービス プロバイダー ユーザー - 組織のクラウド サービス プロバイダーとして機能する組織 (Microsoft Graph パートナー固有の構成の isServiceProvider プロパティは true です)。
• その他の外部ユーザー - これらのカテゴリに該当せず、さらに組織の内部メンバーと見なされないユーザー (つまり、Microsoft Entra ID を介して内部的に認証されず、リソース Microsoft Entra ディレクトリに作成されるユーザー オブジェクトの UserType が "メンバー" ではないユーザー) に適用されます。

条件付きアクセスのユーザー割り当ての詳細について説明します。

外部 ID の条件付きアクセス ポリシーの比較

次の表は、Microsoft Entra 外部 ID のセキュリティ ポリシーとコンプライアンス オプションの詳細な比較を示しています。 セキュリティ ポリシーとコンプライアンスは、条件付きアクセス ポリシーの下でホスト/招待元の組織によって管理されます。

Microsoft Entra 外部ユーザーの MFA

Microsoft Entra テナント間シナリオでは、リソース組織は、すべてのゲスト ユーザーと外部ユーザーに対して MFA またはデバイスのコンプライアンスを要求する条件付きアクセス ポリシーを作成できます。 一般的に、リソースにアクセスする B2B コラボレーション ユーザーは、リソース テナントを使用して Microsoft Entra 多要素認証を設定する必要があります。 ただし、Microsoft Entra ID では、他の Microsoft Entra テナントからの MFA 要求を信頼する機能が提供されるようになりました。 別のテナントとの MFA 信頼を有効にすると、B2B コラボレーション ユーザーのサインイン プロセスが合理化され、B2B 直接接続ユーザーにアクセスできるようになります。

B2B コラボレーションまたは B2B 直接接続ユーザーのホーム テナントからの MFA 要求を受け入れるように受信信頼設定を構成した場合、Microsoft Entra ID はそのユーザーの認証セッションを確認します。 ユーザーのホーム テナントで MFA ポリシーが既に満たされていることを示す要求がセッションに含まれている場合、ユーザーには共有リソースへのシームレスなサインオンが付与されます。

MFA 信頼が有効になっていない場合、B2B コラボレーション ユーザーと B2B 直接接続ユーザーのユーザー エクスペリエンスは異なります。

• B2B コラボレーション ユーザー: リソース組織がユーザーのホーム テナントとの MFA 信頼を有効にしていない場合、ユーザーにはリソース組織からの MFA チャレンジが表示されます。 (フローは Azure AD 外部ユーザー以外のユーザーの MFA フローと同じです。)

• B2B 直接接続ユーザー: リソース組織がユーザーのホーム テナントとの MFA 信頼を有効にしていない場合、ユーザーはアクセスしているリソースからブロックされます。 外部組織との B2B 直接接続を許可する必要があり、条件付きアクセス ポリシーで MFA が必要な場合は、組織からの MFA 要求を受け入れるように、受信信頼設定を構成する必要があります。

MFA の受信信頼設定を構成する方法の詳細について説明します。

Azure AD 外部ユーザー以外のユーザーの MFA

Azure AD 外部ユーザー以外のユーザーの場合、リソース テナントは常に MFA を担当します。 次の例は、一般的な MFA フローを示しています。 このシナリオは、Microsoft アカウント (MSA) やソーシャル ID などの任意の ID に対して機能します。 また、このフローは、ユーザーのホーム Microsoft Entra 組織で信頼設定が構成されていない場合に、その Microsoft Entra 外部ユーザーにも適用されます。

1. Fabrikam という会社の管理者またはインフォメーション ワーカーが、Contoso という別の会社のユーザーを自社のアプリである Woodgrove に招待するとします。

2. Fabrikam のアプリは、アクセス時に Microsoft Entra 多要素認証を必要とするように構成されています。

3. Contoso の B2B コラボレーション ユーザーが Fabrikam のアプリにアクセスしようとする場合、Microsoft Entra 多要素認証のチャレンジの完了が求められます。

4. その後、ゲスト ユーザーは Fabrikam で Microsoft Entra 多要素認証を設定し、オプションを選択できます。

Fabrikam には、Microsoft Entra 多要素認証をサポートするのに十分な Microsoft Entra ID の Premium ライセンスが必要です。 その後、Contoso のユーザーはこの Fabrikam のライセンスを使用します。 B2B ライセンスの詳細については、「Microsoft Entra 外部 ID の課金モデル」を参照してください。

B2B コラボレーション ユーザー向けの Microsoft Entra 多要素認証のリセット (プルーフアップ)

B2B コラボレーション ユーザーから MFA 登録を証明または要求するには、次の PowerShell コマンドレットを使用できます。

1. Microsoft Entra ID に接続します。

   $cred = Get-Credential
   Connect-MsolService -Credential $cred
   

2. 次のようにすべてのユーザーと証明方法を取得します。

   Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
   

   次に例を示します。

   Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
   

3. Microsoft Entra 多要素認証の方法をリセットし、特定のユーザーがもう一度プルーフアップ方法を設定するようにそのユーザーに要求します。例:

   Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.onmicrosoft.com
   

外部ユーザーの認証強度ポリシー

認証強度は、外部ユーザーがリソースへのアクセスで実施する必要がある多要素認証方法の特定の組み合わせを定義できる、条件付きアクセス制御です。 この制御は、組織内の機密性の高いアプリへの外部アクセスを制限する場合に特に役立ちます。外部ユーザーに対して、フィッシングに強い方法などの特定の認証方法を適用できるためです。

また、共同作業や接続を行うさまざまな種類のゲストまたは外部ユーザーに認証強度を適用することもできます。 つまり、B2B コラボレーション、B2B 直接接続、およびその他の外部アクセス シナリオに固有の認証強度要件を適用できます。

Microsoft Entra ID には、3 つの組み込みの認証強度が用意されています。

• 多要素認証強度
• パスワードレス MFA 強度
• フィッシングに強い MFA 強度

これらの組み込み強度のいずれかを使用するか、必要な認証方法に基づいてカスタム認証強度ポリシーを作成できます。

認証強度ポリシーを外部の Microsoft Entra ユーザーに適用すると、ポリシーはテナント間アクセス設定に含まれる MFA 信頼設定と連携して、外部ユーザーが MFA を実行する必要がある場所と方法を決定します。 Microsoft Entra ユーザーは、最初にホーム Microsoft Entra テナントで自分のアカウントを使用して認証を行います。 その後、このユーザーがリソースへのアクセスを試みると、Microsoft Entra ID は認証強度の条件付きアクセス ポリシーを適用し、MFA 信頼が有効になっているかどうかを確認します。

外部ユーザー シナリオでは、ユーザーがホーム テナントとリソース テナントのどちらで MFA を完了しているかによって、認証強度を満たすために許容される認証方法が異なります。 次の表は、各テナントで許容される方法を示しています。 リソース テナントが外部の Microsoft Entra 組織からの要求を信頼することを選んでいる場合、リソース テナントは、MFA の履行のために [ホーム テナント] 列に一覧表示されている要求のみを受け入れます。 リソース テナントで MFA 信頼が無効になっている場合、外部ユーザーは、[リソース テナント] 列に一覧表示されているいずれかの方法を使って、リソース テナントで MFA を完了する必要があります。

表 1 外部ユーザーの認証強度 MFA 方法

外部ユーザーまたはゲストに認証強度の要件を適用する条件付きアクセス ポリシーを構成するには、「条件付きアクセス: 外部ユーザーの認証強度を要求する」を参照してください。

外部 Microsoft Entra ユーザーのユーザー エクスペリエンス

認証強度ポリシーは、クロステナント アクセス設定の MFA 信頼設定と連携して、外部ユーザーが MFA を実行する場所と方法を決定します。

Microsoft Entra ユーザーは、まず、ホーム テナントで自分のアカウントを使って認証を行います。 その後、このユーザーがリソースへのアクセスを試みると、Microsoft Entra ID は認証強度の条件付きアクセス ポリシーを適用し、MFA 信頼が有効になっているかどうかを確認します。

• MFA 信頼が有効になっている場合、Microsoft Entra ID は、ユーザーのホーム テナントで MFA が履行されたことを示す要求がないか、ユーザーの認証セッションを確認します (MFA の履行が外部ユーザーのホーム テナントで完了した場合に許容される認証方法については、「表 1」を参照してください)。ユーザーのホーム テナントで MFA ポリシーが既に満たされていることを示す要求がセッションに含まれていて、その方法が認証強度要件を満たしている場合、ユーザーはアクセスを許可されます。 それ以外の場合、Microsoft Entra ID は、受け入れ可能な認証方法を使用して、ホーム テナントで MFA を完了するチャレンジをユーザーに提示します。 ホーム テナントで MFA 方法を有効にし、ユーザーが登録できるようにする必要があります。
• MFA 信頼が無効な場合、Microsoft Entra ID は、受け入れ可能な認証方法を使用して、リソース テナントで MFA を完了するチャレンジをユーザーに提示します。 (外部ユーザーによる MFA フルフィルメントに許容される認証方法については、表 1 を参照してください。)

ユーザーが MFA を完了できない場合、または条件付きアクセス ポリシー (準拠しているデバイス ポリシーなど) が登録を妨げる場合、アクセスはブロックされます。

デバイス コンプライアンスと Microsoft Entra ハイブリッド参加済みデバイス ポリシー

組織は、条件付きアクセス ポリシーを使用して、ユーザーのデバイスを Microsoft Intune で管理するように要求できます。 このようなポリシーは、外部ユーザーがリソース組織にアンマネージド デバイスを登録できないため、外部ユーザー アクセスをブロックできます。 デバイスは、ユーザーのホーム テナントによってのみ管理できます。

ただし、デバイス信頼設定を使用すると、管理対象デバイスを必要としながらも外部ユーザーのブロックを解除できます。 テナント間アクセス設定では、ユーザーのデバイスがデバイス コンプライアンス ポリシーを満たしているか、または Microsoft Entra ハイブリッド参加済みであるかに関する、外部ユーザーのホーム テナントからの要求を信頼することを選択できます。 すべての Microsoft Entra 組織または個々の組織に対してデバイス信頼設定を設定できます。

デバイス信頼設定が有効になっている場合、Microsoft Entra ID はユーザーの認証セッションでデバイス要求を確認します。 ユーザーのホーム テナントでポリシーが既に満たされていることを示すデバイスの信頼性情報がセッションに含まれている場合、外部ユーザーには共有リソースへのシームレスなサインオンが付与されます。

デバイス フィルター

外部ユーザーの条件付きアクセス ポリシーを作成する場合は、Microsoft Entra ID に登録されているデバイスのデバイス属性に基づいてポリシーを評価できます。 デバイスにフィルターを使用することにより、サポートされている演算子とプロパティ、条件付きアクセスポリシーで使用可能なその他の割り当て条件を使用して、特定のデバイスを対象にすることができるようになりました。

デバイス フィルターは、テナント間アクセス設定と共に使用して、他の組織で管理されているデバイスの基本ポリシーに使用できます。 たとえば、特定のデバイス属性に基づいて、外部の Microsoft Entra テナントからデバイスをブロックするとします。 次の手順を実行して、デバイス属性ベースのポリシーを設定できます。

• テナント間アクセス設定を構成して、その組織からのデバイス要求を信頼します。
• フィルター処理に使用するデバイス属性を、サポートされているデバイス拡張属性のいずれかに割り当てます。
• その属性を含むデバイスへのアクセスをブロックするデバイス フィルターを使用して条件付きアクセス ポリシーを作成します。

条件付きアクセスを使用したデバイスのフィルター処理の詳細について説明します。

モバイル アプリケーション管理ポリシー

外部ユーザーに対してアプリ保護ポリシーを要求はお勧めしません。 承認済みクライアント アプリを必須にするアプリ、およびアプリの保護ポリシーを必須にするポリシーなどの条件付きアクセスの付与管理制御では、リソース テナントにデバイスを登録する必要があります。 これらの制御は、iOS および Android デバイスにのみ適用できます。 ユーザーのデバイスはホーム テナントによってのみ管理できるため、これらのコントロールを外部ゲスト ユーザーに適用することはできません。

場所ベースの条件付きアクセス

招待側組織でパートナー組織を定義する信頼された IP アドレス範囲を作成できる場合は、IP 範囲に基づく場所ベースの条件付きアクセス ポリシーを適用できます。

地理的な場所に基づいてポリシーを適用することもできます。

リスクベースの条件付きアクセス

外部ゲスト ユーザーが許可制御を満たしている場合は、サインイン リスク ポリシーが適用されます。 たとえば、組織で、サインイン リスクが中または高のときに Microsoft Entra 多要素認証を要求できます。 ただし、ユーザーがリソース テナントで以前に Microsoft Entra 多要素認証に登録したことがない場合、そのユーザーはブロックされます。 これは、正当なユーザーのパスワードが侵害された場合に、悪意のあるユーザーが Microsoft Entra 多要素認証の独自の資格情報を登録するのを防ぐために行われます。

ただし、ユーザー リスク ポリシーはリソース テナントで解決できません。 たとえば、リスクの高い外部ゲスト ユーザーに対してパスワードの変更を要求した場合、リソース ディレクトリ内のパスワードをリセットできないため、そのユーザーはブロックされます。

条件付きアクセスのクライアント アプリの条件

クライアント アプリの条件は、B2B ゲスト ユーザーに対しても、他の種類のユーザーの場合と同じように動作します。 たとえば、ゲスト ユーザーがレガシ認証プロトコルを使用するのを防ぐことができます。

条件付きアクセのセッション制御

セッション制御は、B2B ゲスト ユーザーに対しても、他の種類のユーザーの場合と同じように動作します。

Microsoft Entra ID 保護とユーザー リスク ポリシー

Microsoft Entra ID 保護は、Microsoft Entra ユーザーの侵害された認証情報を検出し、侵害される可能性のあるユーザー アカウントを "リスクあり" とマークします。これにより、リソース テナントはユーザー リスク ポリシーを外部ユーザーに適用してリスクのあるサインインをブロックできます。外部ユーザーの場合、ユーザー リスクはそのユーザーのホーム ディレクトリで評価されます。 これらのユーザーのリアルタイムなサインイン リスクは、ユーザーがリソースにアクセスしようとしたときに、リソース ディレクトリで評価されます。 ただし、外部ユーザーの ID はそのユーザーのホーム ディレクトリに存在するため、以下の制限事項が適用されます。

• 外部ユーザーがパスワードのリセットを強制するよう ID 保護ユーザー リスク ポリシーをトリガーした場合、リソース組織内でパスワードをリセットできないため、そのトリガーはブロックされます。
• リスク評価は外部ユーザーのホーム ディレクトリで行われるため、リソース組織のリスクありユーザー レポートには外部ユーザーは反映されません。
• リソース組織内の管理者は、B2B ユーザーのホーム ディレクトリにアクセスできないため、危険な外部ユーザーを無視または修復することはできません。

組織のすべての外部ユーザーを含むグループを Microsoft Entra ID に作成することで、リスクベースのポリシーが外部ユーザーに影響を与えないようにすることができます。 次に、このグループをユーザー リスクおよびサインイン リスクベースの条件付きアクセス ポリシーの除外対象として追加します。

詳しくは、「Microsoft Entra ID 保護と B2B ユーザーについて」を参照してください。

次のステップ

詳細については、次の記事を参照してください。

• ゲスト アクセスと B2B 外部ユーザー アクセスを許可するゼロ信頼ポリシー
• Microsoft Entra ID 保護と B2B ユーザーについて
• よく寄せられる質問 (FAQ)