適切なロール: 管理エージェント |販売エージェント |ヘルプデスク エージェント |課金管理者 |セキュリティ管理者
セキュリティの強化と継続的なセキュリティとプライバシー保護は、Microsoft の最優先事項の 1 つであり、パートナーが顧客とテナントを保護できるように支援し続けています。
パートナーがビジネスや顧客を ID の盗難や不正アクセスから保護できるように、パートナー テナントのセキュリティ保護を強化しました。 これらのセーフガードでは、MFA が義務付けおよび検証されます。 MFA の管理は、パートナーが資格情報の侵害から顧客リソースへのアクセスをセキュリティで保護するのに役立ちます。
この記事では、パートナー センターでの多要素認証 (MFA) の管理に関する詳細な例とガイダンスを示します。
パートナーは、パートナー テナント内のすべてのユーザー アカウント (ゲスト ユーザーを含む) に対して MFA を強制する必要があります。 ユーザーは、次の領域の MFA 検証を完了する必要があります。
- パートナー センター
- パートナー センター API
- パートナー代理管理
サポートされている MFA オプション
- Microsoft を使用するパートナーは、Microsoft Entra 多要素認証をサポートしました。 詳細については、「 Microsoft Entra 多要素認証を有効にする複数の方法 (MFA がサポートされています) を参照してください。
- 統合 MFA フェデレーション認証を実装したパートナー。 これらのパートナー ユーザーは、パートナー センターにアクセスし、GDAP を使用して顧客を管理できます。 AD FS で使用可能な MFA オファリングを備えた統合 MFA プロバイダー: AD FS の 構成方法を参照してください。
重要
パートナーは、Microsoft Entra ID の統合 MFA 要求と互換性のある認証プロバイダーを使用する必要があります。 統合要求は、認証時に提供される実際の資格情報の種類を示します。
パートナー センターおよび API
2026 年 4 月 1 日より、パートナー センター API のすべてのアプリとユーザーの使用で MFA の使用が強制されます。
パートナーは次のオプションを使用できます。
- MFA 要件を満たすために、Microsoft 組み込みの認証方法 を使用します。
- フェデレーション ID プロバイダーを使用している場合 フェデレーションがフェデレーション MFA を受け入れるように構成されていることを確認。
- ADFS を使用して外部の第 2 要素を構成する場合は、AD FS で使用可能な MFA オファリングを持つサード パーティプロバイダーを参照してください: AD FS の認証方法 構成する
- MFA の実装: セキュリティの既定値のガイダンスに従って、セキュリティの既定値または条件付きアクセスを使用してすぐに MFA を有効にします。
この要件に備えるために、2025 年 10 月以降の API は MFA トークンを検索し、応答でその存在を確認します。 詳細については、「 API 呼び出しが MFA と統合されていることを検証する」を参照してください。
検証の例
パートナー センターでの検証のしくみを説明するには、次の例を検討してください。
例 1: パートナーが Microsoft Entra 多要素認証を実装している
Alejandra は Contoso という CSP で動作します。 Contoso は、Microsoft Entra 多要素認証を使用して、Contoso パートナー テナントのすべてのユーザーに対して MFA を実装しました。
Alejandra は新しいブラウザー セッションを開始し、パートナー センターの概要ページに移動します。 パートナー センターは、サインインするために Alejandra を Microsoft Entra ID にリダイレクトします。
Contoso による既存の Microsoft Entra 多要素認証のセットアップにより、MFA 検証を完了するには Alejandra が必要です。 サインインと MFA の検証が成功すると、Alejandra はパートナー センターの概要ページにリダイレクトされます。
Alejandra はパートナー センターへのアクセスを試みます。 以前にサインイン中に Alejandra が MFA 検証を完了したため、Alejandra は MFA で保護されたパートナー センターにアクセスできます。MFA 検証を再度実行する必要はありません。
例 2: パートナーが ID フェデレーションを使用して Microsoft 以外の MFA を実装している
Prashob は Wingtip という CSP に勤めています。 Wingtip は、Microsoft 以外の MFA を使用して Wingtip パートナー テナントのすべてのユーザーに対して MFA を実装しました。これは、ID フェデレーションを介して Microsoft Entra ID と統合されています。
Prashob は新しいブラウザー セッションを開始し、パートナー センターの概要ページに移動します。 パートナー センターは、サインインするために Prashob を Microsoft Entra ID にリダイレクトします。
Wingtip には ID フェデレーションが設定されているため、Microsoft Entra ID は Prashob をフェデレーション ID プロバイダーにリダイレクトして、サインインと MFA の検証を完了します。 サインインと MFA の検証が成功すると、Prashob は Microsoft Entra ID にリダイレクトされ、パートナー センターの概要ページにリダイレクトされます。
Prashob はパートナー センターへのアクセスを試みます。 Prashob は以前にサインイン中に MFA 検証を既に完了しているため、MFA 検証を再度実行する必要なくパートナー センターにアクセスできます。
その後、Prashob はサービス管理ページに移動し、Contoso の Microsoft Entra ID にユーザーを追加します。 Prashob は強力な認証で Entra と互換性のある認証プロバイダーを使用しているため、問題なく顧客テナントにアクセスできます。
この例の Prashob の推奨事項は、Microsoft Entra 多要素認証ソリューションまたは Entra 互換認証プロバイダーを使用して、顧客のテナントを正常に管理できるようにすることです。
例 3: パートナーが MFA を実装していない
Fabrikam という CSP パートナーは、まだ MFA を実装していません。 Microsoft では、Microsoft Entra ID でサポートされる MFA ソリューションを実装する必要があります。
John は Fabrikam に勤めています。 Fabrikam は、Fabrikam パートナー テナントの下のユーザーに対して MFA を実装していません。
John は新しいブラウザー セッションを開始し、パートナー センターの概要ページに移動します。 パートナー センターは、サインインするために John を Microsoft Entra ID にリダイレクトします。
John は MFA 検証を完了していないため、パートナー センターは John を Microsoft Entra ID にリダイレクトして MFA 検証を完了します。 John が MFA を完了する必要があるのはこれが初めてであるため、John は MFA の登録 要求されます。 MFA 登録と MFA 検証が成功すると、John は MFA で保護されたページにアクセスできます。
別の日に、Fabrikam がユーザーの MFA を実装する前に、John は新しいブラウザー セッションを開始し、パートナー センターの概要ページに移動します。 パートナー センターは、John を Microsoft Entra ID にリダイレクトしてサインインし、MFA 検証を完了します。 John は既に MFA を登録しているため、今回は MFA 検証の完了のみを求められます。
例 4: パートナーが Microsoft Entra と互換性のない Microsoft 以外の MFA を実装している
Trent は Wingtip という CSP に勤めています。 Wingtip は、条件付きアクセスを持つクラウド環境で Microsoft 以外の MFA を使用して、Wingtip パートナー テナントのすべてのユーザーに対して MFA を実装しています。
Trent は新しいブラウザー セッションを開始し、パートナー センターの概要ページに移動します。 パートナー センターは、サインインするために Trent を Microsoft Entra ID にリダイレクトします。
Wingtip では、Microsoft Entra ID と互換性のない、強力な認証を持たない Microsoft 以外の MFA 統合が使用されているため、Trent はパートナー センターとパートナー センター内のすべての API へのアクセスをブロックされます。 Trent は、MFA で保護されたページにアクセスするために、強力な認証を MFA に提示する必要があります。
パートナーは、認証時に提供される実際の資格情報の種類を反映して、アクセス トークン要求参照の資格情報メソッド要求 ("amr 要求" - Microsoft ID プラットフォーム) をサポートする Microsoft Entra ID と互換性のある認証プロバイダーを使用する必要があります。
パートナー センター API
パートナー センター API では、アプリのみの認証とアプリケーションとユーザー (アプリ + ユーザー) 認証の両方がサポートされます。
アプリ + ユーザー認証を使用する場合、パートナー センターでは MFA 検証が必要です。 具体的には、パートナー アプリケーションがパートナー センターに API 要求を送信するときに、要求の承認ヘッダーにアクセス トークンを含める必要があります。
注
セキュア アプリケーション モデル フレームワークは、パートナー センター API を呼び出す際に Microsoft Azure MFA アーキテクチャを介して CSP パートナーおよび CPV を認証するためのスケーラブルなフレームワークです。 サービス自動化で MFA を使用する場合は、このフレームワークを実装する必要があります。
パートナー センターが App+User 認証を使用して取得したアクセス トークンを含む API 要求を受信すると、パートナー センター API は、Authentication Method Reference (AMR)要求に MFA 値が存在するか確認します。 JWT デコーダーを使用すると、アクセス トークンに、予測される認証方法参照 (AMR) 値が含まれているかどうかを検証できます。
{
"aud": "https://api.partnercenter.microsoft.com",
"iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
"iat": 1549088552,
"nbf": 1549088552,
"exp": 1549092452,
"acr": "1",
"amr": [
"pwd",
"mfa"
],
"appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
"appidacr": "0",
"family_name": "Adminagent",
"given_name": "CSP",
"ipaddr": "127.0.0.1",
"name": "Adminagent CSP",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"scp": "user_impersonation",
"tenant_region_scope": "NA",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
"unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
"upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
"ver": "1.0"
}
この値が存在する場合、パートナー センターは MFA 検証が完了していると判断し、API 要求を処理します。
値が存在しない場合、パートナー センター API は次の応答で要求を拒否します。
HTTP/1.1 401 Unauthorized - MFA required Transfer-Encoding: chunked Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555 WWW-Authenticate: Bearer error="invalid_token" Date: Thu, 14 Feb 2019 21:54:58 GMT
パートナー センター API を呼び出す場合、アプリ専用アクセス トークンは、顧客テナントでの GDAP ロールの割り当てを必要としない操作でのみサポートされます。
ベスト プラクティスの詳細については、「 API の認証と承認 - 概要」を参照してください。
パートナー代理管理
パートナー テナントは、きめ細かい委任された管理者特権 (GDAP) を使用して、Microsoft Online Services ポータル (portal.azure.com または admin.microsoft.com)、コマンド ライン インターフェイス (CLI)、API (App+ User 認証を使用) を使用して顧客リソースを管理する必要があります。 詳細については、 サポートされている MFA オプションを参照してください。
サービス ポータルの使用
CSP パートナーは、 Partner Center ポータルから サービス管理インターフェイスを使用して顧客を管理できます。 パートナーは顧客に移動し、[サービス管理] を選択して、顧客の特定のサービスを管理できます。 パートナーは、 GDAP ロール ガイダンスに従って 顧客を管理するための適切な最小特権 GDAP ロールを取得する必要があります。
パートナー委任管理者特権 (Admin-On-Behalf-Of) を使用して Microsoft Online Services ポータルにアクセスして顧客リソースを管理する場合、これらのポータルの多くは、顧客の Microsoft Entra テナントを認証コンテキストとして設定して、パートナー アカウントを対話形式で認証する必要があります。 顧客テナントにサインインするには、パートナー アカウントが必要です。
Microsoft Entra ID 認証では、MFA を必要とするポリシーがある場合、ユーザーは MFA 検証を完了する必要があります。 パートナー アカウントがマネージド ID またはフェデレーション ID のどちらであるかに応じて、次の 2 つのユーザー エクスペリエンスが考えられます。
パートナー アカウントが 管理 ID の場合、Microsoft Entra ID はユーザーに MFA 検証の完了を直接求めます。 パートナー アカウントが以前に Microsoft Entra ID で MFA に登録されていない場合、ユーザーは最初に MFA 登録 完了するように求められます 。
パートナー アカウントが federated ID の場合、エクスペリエンスは、パートナー管理者が Microsoft Entra ID でフェデレーションを構成した方法によって異なります。 Microsoft Entra ID でフェデレーションを設定する場合、パートナー管理者は、フェデレーション ID プロバイダーが MFA をサポートしているかどうかを Microsoft Entra ID に指定できます。
- その場合、Microsoft Entra ID はユーザーをフェデレーション ID プロバイダーにリダイレクトして MFA 検証を完了します。
- そうでない場合、Microsoft Entra ID はユーザーに MFA 検証の完了を直接求めます。 パートナー アカウントが以前に Microsoft Entra ID で MFA に登録されていない場合、ユーザーは最初に MFA 登録 完了するように求められます 。
全体的なエクスペリエンスは、エンド カスタマー テナントが管理者に MFA を実装したシナリオに似ています。 たとえば、顧客テナントで Microsoft Entra セキュリティの既定値が有効になっている場合、管理者エージェントやヘルプデスク エージェントなど、MFA 検証を使用して顧客テナントにサインインするには管理者権限を持つすべてのアカウントが必要です。
テスト目的で、パートナーは顧客テナントで Microsoft Entra セキュリティの既定値 を有効にしてから、パートナーの詳細な委任された管理特権 (GDAP) を使用して顧客テナントにアクセスしてみてください。
注
一部の Microsoft Online Service ポータルでは、GDAP を使用して顧客リソースにアクセスするときにパートナー アカウントが顧客テナントにサインインする必要はありません。 代わりに、パートナー アカウントのみがパートナー テナントにサインインする必要があります。 1 つの例は Exchange 管理センターです。 時間の経過と同時に、これらのポータルでは、GDAP を使用するときにパートナー アカウントが顧客テナントにサインインする必要があります。
MFA 登録エクスペリエンス
MFA 検証中に、パートナー アカウントが MFA に登録されていない場合、Microsoft Entra ID はユーザーに最初に MFA 登録を完了するように求めます。
Microsoft Authenticator メソッドの詳細を確認します。
MFA 登録の最初の手順のスクリーンショット。
ユーザーが Next を選択すると、確認方法の一覧から選択するように求められます。
MFA 登録の 2 番目の手順のスクリーンショット。
登録が成功した後、ユーザーは選択した検証方法を使用して MFA 検証を完了する必要があります。
一般的な問題
要求が有効かどうかを理解するには、他のパートナーによって報告された一般的な問題の一覧を確認します。
問題 1: パートナーエージェントに MFA を実装する時間がパートナーに増える必要がある
パートナーが、顧客リソースを管理するためにパートナーの詳細な委任管理権限を使用して Microsoft Online Services ポータルにアクセスする必要があるパートナー エージェントに対して、MFA の導入を開始していないか、またはまだその実装中である可能性があります。 このパートナーには、MFA 実装を完了するためのさらに多くの時間が必要です。 これは、技術的な例外の有効な理由ですか?
回答 : いいえ。 パートナーは、中断を回避するために、ユーザーに MFA を実装する計画を立てる必要があります。
問題 2: パートナーは顧客を管理するためにアクセスする必要がないため、MFA を実装していません
パートナーのテナントには、顧客リソースをパートナーの詳細な委任管理特権を用いて管理するにあたり、Microsoft Online Services ポータルへアクセスする必要のないユーザーがいます。 このパートナーは、これらのユーザーに対して MFA を実装している最中であり、完了にはさらに時間が必要です。 これは、技術的な例外の有効な理由ですか?
回答 : いいえ。 これらのユーザー アカウントは、顧客のリソースを管理するための「パートナー詳細委任管理権限」を使用していないため、顧客テナントにサインインする必要はありません。 顧客リソースを管理するには、すべてのユーザーがパートナー センターまたは顧客ワークロードにアクセスする MFA を持っている必要があります。
問題 3: パートナーがユーザー サービス アカウントに MFA を実装していない
あるパートナーのパートナー テナントに、サービス アカウントとしてデバイスに使用されているいくつかのユーザー アカウントが存在します。 これらの低い特権のアカウントでは、パートナーの詳細な委任された管理特権を使用して顧客リソースを管理するために、パートナー センターや Microsoft Online Services ポータルにアクセスする必要はありません。 これは技術的な例外の正当な理由ですか?
回答 : いいえ。 これらのユーザーアカウントは、顧客リソースを管理するためにパートナーの詳細委任管理特権を使用していないため、顧客テナントにサインインする必要がありません。 API またはポータルでアプリとユーザーの認証が必要な場合、すべてのユーザーが認証に MFA を使用する必要があります。
問題 4: パートナーが Microsoft Authenticator アプリを使用して MFA を実装できない
パートナーには "クリーン デスク" ポリシーがあり、従業員が個人のモバイル デバイスを職場に持ち込むことは許可されていません。 個人のモバイル デバイスにアクセスしないと、従業員は Microsoft Authenticator アプリをインストールできません。これは、Microsoft Entra セキュリティの既定値でサポートされている唯一の MFA 検証です。 これは、技術的な例外の有効な理由ですか?
回答 : いいえ。 パートナー センターにアクセスするときに従業員が MFA 検証を完了できるように、パートナーは次の代替手段を検討する必要があります。
- パートナーは、Microsoft Entra ID P1 または P2 にサインアップすることも、Microsoft Entra ID と互換性のある Microsoft 以外の MFA ソリューションを使用して、より多くの検証方法を提供することもできます。 詳細については、 Authentication メソッドのサポートを参照してください。
問題 5: レガシ認証プロトコルの使用により、パートナーが MFA を実装できない
あるパートナーの一部のパートナー エージェントが、MFA と互換性のないレガシ認証プロトコルを引き続き使用しています。 たとえば、ユーザーが、レガシ認証プロトコルに基づく Outlook 2010 を引き続き使用しています。 これらのパートナー エージェントに対して MFA を有効にすると、レガシ認証プロトコルの使用が中断されます。 これは、技術的な例外の有効な理由ですか?
回答 : いいえ。 パートナーは、これらのプロトコルを MFA 検証で保護することはできないため、セキュリティへの影響が考えられるため、レガシ認証プロトコルの使用から離れ、資格情報の侵害の影響を受けやすくすることをお勧めします。 レガシ認証を非推奨にし、セキュリティの既定値または条件付きアクセスを使用することをお勧めします。 レガシ認証から移行する準備をするには、レガシ認証ブックを使用して サインインを確認し レガシ認証をブロックする方法 ガイダンスを確認。
Outlook のレガシ認証をサポートするための最新の計画を理解するには、Basic 認証と Exchange Online に関する投稿を読みExchange チームのブログに従って今後のニュースを入手してください。
問題 6: パートナーが Microsoft Entra ID で認識されない Microsoft 以外の MFA を実装しました
パートナーは、Microsoft 以外の MFA ソリューションを使用してユーザーに MFA を実装しました。 ただし、パートナーは、ユーザー認証中に MFA 検証が完了したことを Microsoft Entra ID にリレーするように Microsoft 以外の MFA ソリューションを正しく構成できません。 これは、技術的な例外の有効な理由ですか?
回答: いいえ。パートナーは、認証時に提供される実際の資格情報の種類を反映して、資格情報メソッド要求 ("AMR")、Access トークン要求参照 ( Microsoft ID プラットフォーム) をサポートする Microsoft Entra ID と互換性のある認証プロバイダーを使用する必要があります。
パートナーには中断を回避するため、Microsoft Entra ID と互換性のある MFA ソリューションを実装することが求められています。