外部 ID の認証と条件付きアクセス
ヒント
この記事は、B2B コラボレーションと B2B 直接接続を対象としています。 テナントが顧客の ID およびアクセス管理用に構成されている場合は、「顧客用の Microsoft Entra ID でのセキュリティとガバナンス」を参照してください。
外部ユーザーが組織内のリソースにアクセスする場合、認証フローは、コラボレーション方法 (B2B コラボレーションまたは B2B 直接接続)、ユーザーの ID プロバイダー (外部の Microsoft Entra テナント、ソーシャル ID プロバイダーなど)、条件付きアクセス ポリシー、およびユーザーのホーム テナントとテナント ホスティング リソースの両方で構成されたテナント間アクセス設定によって決まります。
この記事では、組織内のリソースにアクセスしている外部ユーザーの認証フローについて説明します。 組織は、外部ユーザーに対して複数の条件付きアクセス ポリシーを適用できます。これは、組織のフルタイムの従業員とメンバーに対して有効にしたのと同じ方法で、テナント、アプリ、または個々のユーザー レベルで適用できます。
外部 Microsoft Entra ユーザーの認証フロー
次の図は、Microsoft Entra 組織がリソースを他の Microsoft Entra 組織からのユーザーと共有する場合の認証フローを示しています。 この図は、テナント間のアクセス設定が多要素認証などの条件付きアクセス ポリシーと連携して、ユーザーがリソースにアクセスできるかどうかを判断する方法を示しています。 このフローは、手順 6 で示されている場合を除き、B2B コラボレーションと B2B 直接接続の両方に適用されます。
| 手順 | 説明 |
|---|---|
| 1 | Fabrikam (ユーザーのホーム テナント) のユーザーが、Contoso (リソース テナント) のリソースへのサインインを開始します。 |
| 2 | サインイン中に、Microsoft Entra セキュリティ トークン サービス (STS) によって Contoso の条件付きアクセス ポリシーが評価されます。 また、テナント間アクセス設定 (Fabrikam の送信設定と Contoso の受信設定) を評価することで、Fabrikam ユーザーがアクセスを許可されているかどうかを確認します。 |
| 3 | Microsoft Entra ID は Contoso の受信信頼設定を検査して、Contoso が Fabrikam からの MFA とデバイス要求 (デバイス コンプライアンス、Microsoft Entra ハイブリッド参加済み状態) を信頼しているかどうかを確認します。 必要ない場合は、手順 6 に進みます。 |
| 4 | Contoso が Fabrikam からの MFA とデバイスの信頼性情報を信頼している場合、Microsoft Entra ID はユーザーの認証セッションを検査して、ユーザーが MFA を完了したことを確認します。 Contoso が Fabrikam からのデバイス情報を信頼している場合、Microsoft Entra ID は、デバイスの状態 (準拠または Microsoft Entra ハイブリッド参加済み) を示す要求を認証セッションで検索します。 |
| 5 | MFA が必須であるが完了していない場合、またはデバイス要求が指定されていない場合、Microsoft Entra ID は必要に応じてユーザーのホーム テナントで MFA とデバイス チャレンジを発行します。 Fabrikam で MFA とデバイスの要件が満たされている場合、ユーザーは Contoso のリソースへのアクセスを許可されます。 その確認事項を満たすことができない場合、アクセスはブロックされます。 |
| 6 | 信頼設定が構成されておらず、MFA が必要な場合、B2B コラボレーション ユーザーは MFA を要求されます。 リソース テナントで MFA を満たす必要があります。 B2B 直接接続ユーザーのアクセスはブロックされます。 デバイスのコンプライアンスが必要だが評価できない場合、B2B コラボレーションと B2B 直接接続の両方のユーザーのアクセスがブロックされます。 |
詳細については、「外部ユーザーの条件付きアクセス」セクションを参照してください。
Azure AD 外部ユーザー以外の認証フロー
Microsoft Entra 組織が Microsoft Entra ID 以外の ID プロバイダーを使用してリソースを外部ユーザーと共有する場合、認証フローは、ユーザーが ID プロバイダーまたは電子メール ワンタイム パスコード認証を使用して認証を行うかどうかによって異なります。 どちらの場合でも、リソース テナントは、使用する認証方法を識別し、ユーザーを ID プロバイダーにリダイレクトするか、ワンタイム パスコードを発行します。
例 1: Azure AD 外部ユーザー以外のユーザーの認証フローおよびトークン
次の図は、外部ユーザーが Google、Facebook、フェデレーション SAML/WS-Fed ID プロバイダーなど、Azure AD 以外の ID プロバイダーのアカウントでサインインする場合の認証フローを示しています。
| 手順 | 説明 |
|---|---|
| 1 | B2B ゲスト ユーザーが、あるリソースへのアクセスを要求します。 このリソースで、ユーザーをそのリソース テナント (信頼された IdP) にリダイレクトします。 |
| 2 | リソース テナントで、ユーザーを外部として識別し、B2B ゲスト ユーザーの IdP にリダイレクトします。 ユーザーは IdP でプライマリ認証を実行します。 |
| 3 | 承認ポリシーは、B2B ゲスト ユーザーの IdP で評価されます。 ユーザーがこれらのポリシーを満たす場合、B2B ゲスト ユーザーの IdP はユーザーへトークンを発行します。 ユーザーはトークンとともにリソース テナントにリダイレクトされます。 リソース テナントはトークンを検証した後、ユーザーをその条件付きアクセス ポリシーに照らして評価します。 たとえば、リソース テナントでは、ユーザーが Microsoft Entra 多要素認証を実行するように要求する場合があります。 |
| 4 | 受信テナント間アクセス設定と条件付きアクセス ポリシーが評価されます。 すべてのポリシーが満たされる場合、リソース テナントで独自のトークンを発行し、ユーザーをそのリソースにリダイレクトします。 |
例 2: ワンタイム パスコード ユーザーの認証フローとトークン
次の図は、電子メール ワンタイム パスコード認証が有効で、外部ユーザーが Microsoft Entra ID、Microsoft アカウント (MSA)、ソーシャル ID プロバイダーなどの他の方法では認証されない場合のフローを示しています。
| 手順 | 説明 |
|---|---|
| 1 | ユーザーが、別のテナントのリソースへのアクセスを要求します。 このリソースで、ユーザーをそのリソース テナント (信頼された IdP) にリダイレクトします。 |
| 2 | リソース テナントで、ユーザーを外部のメール ワンタイム パスコード (OTP) ユーザーとして識別し、OTP を含むメールをユーザーに送信します。 |
| 3 | ユーザーが OTP を取得し、コードを送信します。 リソース テナントで、ユーザーをその条件付きアクセス ポリシーに照らして評価します。 |
| 4 | すべての条件付きアクセス ポリシーが満たされると、リソース テナントでトークンを発行し、ユーザーをそのリソースにリダイレクトします。 |
外部ユーザーの条件付きアクセス
組織は、組織のフルタイムの従業員とメンバーに対して有効にしたのと同じ方法で、外部の B2B コラボレーションおよび B2B 直接接続ユーザーに条件付きアクセス ポリシーを適用できます。 テナント間アクセス設定を導入すると、外部の Microsoft Entra 組織からの MFA とデバイス要求を信頼することもできます。 このセクションでは、組織外のユーザーに条件付きアクセスを適用する際の重要な考慮事項について説明します。
Note
条件付きアクセスを使用するカスタムコントロールは、テナント間の信頼ではサポートされていません。
外部ユーザーの種類への条件付きアクセス ポリシーの割り当て
条件付きアクセス ポリシーを構成する際に、ポリシーを適用する外部ユーザーの種類をきめ細かく制御できます。 外部ユーザーは、認証方法 (内部または外部) および組織との関係 (ゲストまたはメンバー) に基づいて分類されます。
- 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 が "メンバー" ではないユーザー) に適用されます。
Note
[すべてのゲストと外部ユーザー] の選択は、[Guest and external users] (ゲストと外部ユーザー) とそのすべてのサブタイプに置き換えられました。 以前に [すべてのゲストと外部ユーザー] が選択された条件付きアクセス ポリシーを使用していたお客様の場合は、すべてのサブタイプが選択された状態で [Guest and external users] (ゲストと外部ユーザー) が表示されるようになります。 UX のこの変更は、条件付きアクセス バックエンドによるポリシーの評価方法に機能的な影響はありません。 この新しい選択により、お客様は、条件付きアクセス ポリシーの作成時にユーザー スコープに含める、または除外するゲストと外部ユーザーの特定の種類を選択するために必要な細分性が得られます。
条件付きアクセスのユーザー割り当ての詳細について説明します。
外部 ID の条件付きアクセス ポリシーの比較
次の表は、Microsoft Entra 外部 ID のセキュリティ ポリシーとコンプライアンス オプションの詳細な比較を示しています。 セキュリティ ポリシーとコンプライアンスは、条件付きアクセス ポリシーの下でホスト/招待元の組織によって管理されます。
| ポリシー | B2B コラボレーション ユーザー | B2B 直接接続ユーザー |
|---|---|---|
| 制御の許可 - アクセスをブロックする | サポートされています | サポートされています |
| 制御の許可 - 多要素認証を要求する | サポートされています | サポートされています。外部組織からの MFA 要求を受け入れるように受信信頼設定を構成する必要があります |
| 制御の許可 - 準拠しているデバイスが必要 | サポートされています。外部組織からの準拠デバイス要求を受け入れるように受信信頼設定を構成する必要があります。 | サポートされています。外部組織からの準拠デバイス要求を受け入れるように受信信頼設定を構成する必要があります。 |
| 制御の許可 - Microsoft Entra ハイブリッド参加済みデバイスが必要 | サポートされています。外部組織からの Microsoft Entra ハイブリッド参加済みデバイス要求を受け入れるように受信信頼設定を構成する必要があります | サポートされています。外部組織からの Microsoft Entra ハイブリッド参加済みデバイス要求を受け入れるように受信信頼設定を構成する必要があります |
| 制御の許可 - 承認されたクライアント アプリが必要 | サポート対象外 | サポート対象外 |
| 制御の許可 - アプリ保護ポリシーが必要 | サポート対象外 | サポート対象外 |
| 制御の許可 - パスワードの変更を要求する | サポート対象外 | サポート対象外 |
| 制御の許可 - 使用条件 | サポートされています | サポートされていません |
| セッション制御 - アプリによって適用される制限を使用 | サポートされています | サポートされていません |
| セッション制御 - アプリの条件付きアクセス制御を使う | サポートされています | サポートされていません |
| セッション制御 - サインインの頻度 | サポートされています | サポートされていません |
| セッション制御 - 永続的なブラウザー セッション | サポートされています | サポートされていません |
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 外部ユーザーにも適用されます。
Fabrikam という会社の管理者またはインフォメーション ワーカーが、Contoso という別の会社のユーザーを自社のアプリである Woodgrove に招待するとします。
Fabrikam のアプリは、アクセス時に Microsoft Entra 多要素認証を必要とするように構成されています。
Contoso の B2B コラボレーション ユーザーが Fabrikam のアプリにアクセスしようとする場合、Microsoft Entra 多要素認証のチャレンジの完了が求められます。
その後、ゲスト ユーザーは Fabrikam で Microsoft Entra 多要素認証を設定し、オプションを選択できます。
Fabrikam には、Microsoft Entra 多要素認証をサポートするのに十分な Microsoft Entra ID の Premium ライセンスが必要です。 その後、Contoso のユーザーはこの Fabrikam のライセンスを使用します。 B2B ライセンスの詳細については、「Microsoft Entra 外部 ID の課金モデル」を参照してください。
Note
MFA は、予測可能性を確保するために、リソース テナントで完了します。 ゲスト ユーザーがサインインすると、リソース テナントのサインイン ページが背景に、独自のホーム テナントのサインイン ページと会社のロゴが前景に表示されます。
B2B コラボレーション ユーザー向けの Microsoft Entra 多要素認証のリセット (プルーフアップ)
B2B コラボレーション ユーザーから MFA 登録を証明または要求するには、次の PowerShell コマンドレットを使用できます。
Note
Azure AD および MSOnline PowerShell モジュールは、2024 年 3 月 30 日の時点で非推奨となります。 詳細については、非推奨の最新情報を参照してください。 この日以降、これらのモジュールのサポートは、Microsoft Graph PowerShell SDK への移行支援とセキュリティ修正プログラムに限定されます。 非推奨になるモジュールは、2025 年 3 月 30 日まで引き続き機能します。
Microsoft Entra ID (旧称 Azure AD) を使用するには、Microsoft Graph PowerShell に移行することをお勧めします。 移行に関する一般的な質問については、「移行に関する FAQ」を参照してください。 注: バージョン 1.0.x の MSOnline では、2024 年 6 月 30 日以降に中断が発生する可能性があります。
Microsoft Entra ID に接続します。
$cred = Get-Credential Connect-MsolService -Credential $cred次のようにすべてのユーザーと証明方法を取得します。
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}次に例を示します。
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}Microsoft Entra 多要素認証の方法をリセットし、特定のユーザーがもう一度プルーフアップ方法を設定するようにそのユーザーに要求します。例:
Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.onmicrosoft.com
外部ユーザーの認証強度ポリシー
認証強度は、外部ユーザーがリソースへのアクセスで実施する必要がある多要素認証方法の特定の組み合わせを定義できる、条件付きアクセス制御です。 この制御は、組織内の機密性の高いアプリへの外部アクセスを制限する場合に特に役立ちます。外部ユーザーに対して、フィッシングに強い方法などの特定の認証方法を適用できるためです。
また、共同作業や接続を行うさまざまな種類のゲストまたは外部ユーザーに認証強度を適用することもできます。 つまり、B2B コラボレーション、B2B 直接接続、およびその他の外部アクセス シナリオに固有の認証強度要件を適用できます。
Microsoft Entra ID には、3 つの組み込みの認証強度が用意されています。
- 多要素認証強度
- パスワードレス MFA 強度
- フィッシングに強い MFA 強度
これらの組み込み強度のいずれかを使用するか、必要な認証方法に基づいてカスタム認証強度ポリシーを作成できます。
Note
現時点では、Microsoft Entra ID で認証する外部ユーザーにのみ認証強度ポリシーを適用できます。 メールのワンタイム パスコード、SAML/WS-Fed、Google フェデレーション ユーザーの場合は、MFA 許可コントロールを使用して MFA を要求します。
認証強度ポリシーを外部の Microsoft Entra ユーザーに適用すると、ポリシーはテナント間アクセス設定に含まれる MFA 信頼設定と連携して、外部ユーザーが MFA を実行する必要がある場所と方法を決定します。 Microsoft Entra ユーザーは、最初にホーム Microsoft Entra テナントで自分のアカウントを使用して認証を行います。 その後、このユーザーがリソースへのアクセスを試みると、Microsoft Entra ID は認証強度の条件付きアクセス ポリシーを適用し、MFA 信頼が有効になっているかどうかを確認します。
外部ユーザー シナリオでは、ユーザーがホーム テナントとリソース テナントのどちらで MFA を完了しているかによって、認証強度を満たすために許容される認証方法が異なります。 次の表は、各テナントで許容される方法を示しています。 リソース テナントが外部の Microsoft Entra 組織からの要求を信頼することを選んでいる場合、リソース テナントは、MFA の履行のために [ホーム テナント] 列に一覧表示されている要求のみを受け入れます。 リソース テナントで MFA 信頼が無効になっている場合、外部ユーザーは、[リソース テナント] 列に一覧表示されているいずれかの方法を使って、リソース テナントで MFA を完了する必要があります。
表 1 外部ユーザーの認証強度 MFA 方法
| 認証方法 | ホーム テナント | リソース テナント |
|---|---|---|
| 第 2 の要素としての SMS | ✅ | ✅ |
| 音声通話 | ✅ | ✅ |
| Microsoft Authenticator プッシュ通知 | ✅ | ✅ |
| Microsoft Authenticator の電話によるサインイン | ✅ | ✅ |
| OATH ソフトウェア トークン | ✅ | ✅ |
| OATH ハードウェア トークン | ✅ | |
| FIDO2 セキュリティ キー | ✅ | |
| Windows Hello for Business | ✅ |
外部ユーザーまたはゲストに認証強度の要件を適用する条件付きアクセス ポリシーを構成するには、「条件付きアクセス: 外部ユーザーの認証強度を要求する」を参照してください。
外部 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 ハイブリッド参加済み状態に関する要求を信頼する場合を除き、外部ユーザーがマネージド デバイスを使用することを要求する条件付きアクセス ポリシーを適用することはお勧めしません。
デバイス フィルター
外部ユーザーの条件付きアクセス ポリシーを作成する場合は、Microsoft Entra ID に登録されているデバイスのデバイス属性に基づいてポリシーを評価できます。 デバイスにフィルターを使用することにより、サポートされている演算子とプロパティ、条件付きアクセスポリシーで使用可能なその他の割り当て条件を使用して、特定のデバイスを対象にすることができるようになりました。
デバイス フィルターは、テナント間アクセス設定と共に使用して、他の組織で管理されているデバイスの基本ポリシーに使用できます。 たとえば、特定のデバイス属性に基づいて、外部の Microsoft Entra テナントからデバイスをブロックするとします。 次の手順を実行して、デバイス属性ベースのポリシーを設定できます。
- テナント間アクセス設定を構成して、その組織からのデバイス要求を信頼します。
- フィルター処理に使用するデバイス属性を、サポートされているデバイス拡張属性のいずれかに割り当てます。
- その属性を含むデバイスへのアクセスをブロックするデバイス フィルターを使用して条件付きアクセス ポリシーを作成します。
条件付きアクセスを使用したデバイスのフィルター処理の詳細について説明します。
モバイル アプリケーション管理ポリシー
外部ユーザーに対してアプリ保護ポリシーを要求はお勧めしません。 承認済みクライアント アプリを必須にするアプリ、およびアプリの保護ポリシーを必須にするポリシーなどの条件付きアクセスの付与管理制御では、リソース テナントにデバイスを登録する必要があります。 これらの制御は、iOS および Android デバイスにのみ適用できます。 ユーザーのデバイスはホーム テナントによってのみ管理できるため、これらのコントロールを外部ゲスト ユーザーに適用することはできません。
場所ベースの条件付きアクセス
招待側組織でパートナー組織を定義する信頼された IP アドレス範囲を作成できる場合は、IP 範囲に基づく場所ベースの条件付きアクセス ポリシーを適用できます。
地理的な場所に基づいてポリシーを適用することもできます。
リスクベースの条件付きアクセス
外部ゲスト ユーザーが許可制御を満たしている場合は、サインイン リスク ポリシーが適用されます。 たとえば、組織で、サインイン リスクが中または高のときに Microsoft Entra 多要素認証を要求できます。 ただし、ユーザーがリソース テナントで以前に Microsoft Entra 多要素認証に登録したことがない場合、そのユーザーはブロックされます。 これは、正当なユーザーのパスワードが侵害された場合に、悪意のあるユーザーが Microsoft Entra 多要素認証の独自の資格情報を登録するのを防ぐために行われます。
ただし、ユーザー リスク ポリシーはリソース テナントで解決できません。 たとえば、リスクの高い外部ゲスト ユーザーに対してパスワードの変更を要求した場合、リソース ディレクトリ内のパスワードをリセットできないため、そのユーザーはブロックされます。
条件付きアクセスのクライアント アプリの条件
クライアント アプリの条件は、B2B ゲスト ユーザーに対しても、他の種類のユーザーの場合と同じように動作します。 たとえば、ゲスト ユーザーがレガシ認証プロトコルを使用するのを防ぐことができます。
条件付きアクセのセッション制御
セッション制御は、B2B ゲスト ユーザーに対しても、他の種類のユーザーの場合と同じように動作します。
ID 保護とユーザー リスク ポリシー
Identity Protection は、Microsoft Entra ユーザーの侵害された資格情報を検出し、侵害される可能性のあるユーザー アカウントを "リスクあり" とマークします。リソース テナントとして、ユーザー リスク ポリシーを外部ユーザーに適用して、危険なサインインをブロックできます。外部ユーザーの場合、ユーザー リスクはホーム ディレクトリで評価されます。 これらのユーザーのリアルタイムなサインイン リスクは、ユーザーがリソースにアクセスしようとしたときに、リソース ディレクトリで評価されます。 ただし、外部ユーザーの ID はホーム ディレクトリに存在するため、制限事項は次のとおりです。
- 外部ユーザーがパスワードのリセットを強制するために Identity Protection ユーザー リスク ポリシーをトリガーした場合、リソース組織内でパスワードをリセットできないため、ブロックされます。
- リソース組織の危険なユーザー レポートには、外部ユーザーのホーム ディレクトリでリスク評価が行われるため、外部ユーザーは反映されません。
- リソース組織内の管理者は、B2B ユーザーのホーム ディレクトリにアクセスできないため、危険な外部ユーザーを無視または修復することはできません。
組織のすべての外部ユーザーを含むグループを Microsoft Entra ID に作成することで、リスクベースのポリシーが外部ユーザーに影響を与えないようにすることができます。 その後、このグループを、組み込みの Identity Protection ユーザー リスク ポリシーとサインイン リスク ポリシー、およびサインイン リスクを条件として使用している条件付きアクセス ポリシーの除外対象として追加します。
詳しくは、「Identity Protection と B2B ユーザー」をご覧ください。
次のステップ
詳細については、次の記事を参照してください。