外部 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 コラボレーション メンバー ユーザー - このカテゴリの 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 という別の会社のユーザーを、Fabrikam のアプリの使用に招待するとします。

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

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

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

これには、Fabrikam が、Microsoft Entra 多要素認証のサポートに必要な Microsoft Entra ID の プレミアム ライセンスを持っている必要があります。 その後、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)