GDAP に関してよく寄せられる質問

パートナー組織の 管理エージェント ロールを持つユーザーは、GDAP リレーションシップ要求作成できます。

はい。 GDAP リレーションシップ要求は、90 日後に期限切れになります。

いいえ。 セキュリティ上の理由から、お客様との永続的な GDAP リレーションシップを使用することはできません。 GDAP リレーションシップの最大期間は 2 年です。 自動拡張 を Enabled に設定して、管理者関係を 6 か月延長するか、または自動拡張を Disabledに設定します。

いいえ。 GDAP リレーションシップでは、エンタープライズ契約を通じて購入されたサブスクリプションはサポートされていません。

はい。 GDAP リレーションシップは、終了するか、自動拡張が無効に設定されるまで、6 か月間自動拡張できます。

• 顧客との GDAP 関係の有効期限が切れた場合は、 再度 GDAP リレーションシップを要求します。
• GDAP リレーションシップ分析 を使用して、GDAP リレーションシップの有効期限を追跡し、更新の準備を行うことができます。

GDAP 関係を延長または更新するには、パートナーまたは顧客が 自動拡張 を Enabledに設定する必要があります。 詳細については、「管理 GDAP Auto extend および API」を参照してください。

はい。 GDAP がアクティブな場合は、拡張できます。

たとえば、自動拡張が [有効] に設定された状態で GDAP が 365 日間作成されるとします。 365 日目に、終了日は実質的に 180 日更新されます。

はい。 アクティブな GDAP を自動的に拡張できます。

いいえ。 既存のアクティブな GDAP に対して自動拡張を有効に設定するために、お客様の同意は必要ありません。

いいえ。 セキュリティ グループに割り当てられている詳細なアクセス許可は、引き続き as-is。

いいえ。 グローバル管理者ロールを使用して管理者関係を自動拡張することはできません。

[期限切れの詳細なリレーションシップ] ページは、グローバル管理者ロールと管理エージェント ロールを持つパートナー ユーザーのみが使用できます。 このページは、異なるタイムライン間で期限切れの CSP をフィルター処理するのに役立ち、1 つ以上の GDP の自動更新 (有効化/無効化) を更新するのに役立ちます。

いいえ。 GDAP リレーションシップの有効期限が切れたときに、顧客の既存のサブスクリプションに変更はありません。

ガイダンスについては、「Microsoft Entra 多要素認証の問題のトラブルシューティング し、Microsoft Entra 多要素認証を使用して、電話を紛失した後、または電話番号の変更 後にクラウド サービスにサインインすることはできません。

パートナーは、最初の GDAP の作成時に Microsoft Entra ロール 特権認証管理者を要求する必要があります。

• このロールにより、パートナーは管理者または管理者以外のユーザーのパスワードと認証方法をリセットできます。 特権認証管理者ロールは、Microsoft Led Tool によって設定されたロールの一部であり、顧客の作成フロー中に既定の GDAP で使用できるようになる予定です (9 月に予定)。
• パートナーは、顧客管理者にパスワードのリセット 試みしてもらう可能性があります。
• 予防措置として、パートナーは顧客に対して SSPR (セルフサービス パスワード リセット) を設定する必要があります。 詳細については、「ユーザーが自分のパスワードをリセットできるようにする」を参照してください。

• パートナー 組織内で、管理エージェント ロールを持つユーザーは、終了通知を受け取ります。
• 顧客 組織内で、グローバル管理者 ロールを持つユーザーは、終了通知を受け取ります。

はい。 パートナーは、パートナー センターのアクティビティ ログで顧客が GDAP を削除するタイミングを確認できます。

いいえ。 GDAP は、顧客のサービスをより細かく期限付きの方法で管理したいパートナー向けのオプション機能です。 GDAP リレーションシップを作成する顧客を選択できます。

その答えは、顧客を管理する方法によって異なります。

• パートナー ユーザーがすべての顧客を管理できるようにする場合は、すべてのパートナー ユーザーを 1 つのセキュリティ グループに配置し、1 つのグループですべての顧客を管理できます。
• さまざまなパートナー ユーザーがさまざまな顧客を管理することを希望する場合は、顧客を分離するためにそれらのパートナー ユーザーを個別のセキュリティ グループに割り当てます。

はい。 間接リセラー (および間接プロバイダーと直接請求パートナー) は、パートナー センターで GDAP リレーションシップ要求を作成できます。

GDAP セットアップの一環として、パートナー ユーザーと共にパートナー テナントで作成されたセキュリティ グループが選択されていることを確認します。 また、目的の Microsoft Entra ロールがセキュリティ グループに割り当てられていることを確認します。 「Microsoft Entra ロール割り当てる」を参照してください。

パートナーがブロックされることなく GDAP に移行できるように、条件付きアクセス ポリシーから CSP を除外できるようになりました。

• ユーザーの を含める - このユーザーの一覧には、通常、組織が条件付きアクセス ポリシーで対象としているすべてのユーザーが含まれます。
• 条件付きアクセス ポリシーを作成するときに、次のオプションを含めることができます。
• ユーザーとグループを選択する
• ゲスト ユーザーまたは外部ユーザー (プレビュー)
• この選択では、条件付きアクセス ポリシーを特定のゲストまたは外部ユーザーの種類と、それらの種類のユーザーを含む特定のテナントを対象にするために使用できるいくつかの選択肢が提供されます。 選択できるゲスト ユーザーまたは外部ユーザーにはさまざまな種類があり、複数の選択を行うことができます。
• クラウド ソリューション プロバイダー (CSP) などのサービス プロバイダー ユーザー。
• 選択したユーザーの種類に 1 つ以上のテナントを指定することも、すべてのテナントを指定することもできます。
• 外部パートナー アクセス - 外部ユーザーを対象とする条件付きアクセス ポリシーは、サービス プロバイダーのアクセス (詳細な委任された管理者特権など) に干渉する可能性があります。 詳細については、「詳細な委任された管理者特権 (GDAP)の概要」を参照してください。 サービス プロバイダー テナントを対象とするポリシーの場合は、サービス プロバイダー ユーザーを使用、ゲストまたは外部ユーザーの選択オプションで使用できる外部ユーザーの種類 します。
• ユーザーを除外する - 組織がユーザーまたはグループを含める場合と除外する場合、除外アクションによってポリシーに含めるアクションがオーバーライドされるため、ユーザーまたはグループはポリシーから除外されます。
• 条件付きアクセス ポリシーを作成するときに除外するには、次のオプションを使用できます。
• ゲスト ユーザーまたは外部ユーザー
• この選択では、条件付きアクセス ポリシーを特定のゲストまたは外部ユーザーの種類と、それらの種類のユーザーを含む特定のテナントを対象にするために使用できるいくつかの選択肢が提供されます。 選択できるゲスト ユーザーまたは外部ユーザーには、いくつかの異なる種類 があり、複数の選択を行うことができます。
• クラウド ソリューション プロバイダー (CSP) などのサービス プロバイダー ユーザー
• 選択したユーザーの種類に対して 1 つ以上のテナントを指定することも、すべてのテナントを指定することもできます。 詳細については、以下を参照してください。
• Graph API エクスペリエンス: 新しい外部ユーザーの種類情報を含むベータ API
• 条件付きアクセス ポリシーの を する
• 条件付きアクセスの外部ユーザー を する

はい。 サポート プランに関係なく、パートナー ユーザーが顧客のサポート チケットを作成できる最も特権の低いロールは、サービス サポート管理者です。

いいえ。 パートナーは現在、承認保留中 状態で GDAP を終了できません。 顧客がアクションを実行しない場合、90 日以内に有効期限が切れます。

GDAP リレーションシップが終了または期限切れになってから 365 日後 (クリーンアップ) 後にのみ、同じ名前を再利用して新しい GDAP リレーションシップを作成できます。

はい。 パートナーは、顧客リージョンごとに新しいパートナー テナントを作成することなく、リージョン間で顧客を管理できます。 これは、GDAP (管理者リレーションシップ) によって提供される顧客管理ロールにのみ適用されます。 トランザクションの役割と機能は、引き続き 承認済みの Territoryに制限されます。

いいえ。 サービス プロバイダーはマルチテナント組織に参加することはできません。これらは相互に排他的です。

1. セキュリティ グループの アクセス許可を付与する方法など、GDAP が適切に設定されていることを確認。
2. 詳細な セキュリティ グループのアクセス許可 が正しいことを確認します。
3. ヘルプについては、Security Copilot の FAQ を参照してください。

API と GDAP の詳細については、パートナー センターの開発者向けドキュメントを参照してください。

はい。 パートナーは、運用環境に ベータ GDAP API を使用し、使用可能になったら後で API v.1 に切り替えすることをお勧めします。 "運用アプリケーションでのこれらの API の使用はサポートされていません" という警告がありますが、一般的なガイダンスは Graph のベータ版 API 用であり、ベータ GDAP Graph API には適用されません。

はい。 パートナーがこのプロセスをスケーリングできるようにする API を使用して GDAP リレーションシップを作成できます。 ただし、パートナー センターでは、複数の GDAP リレーションシップを作成することはできません。 API と GDAP の詳細については、パートナー センターの開発者向けドキュメントを参照してください。

API は一度に 1 つのセキュリティ グループに対して機能しますが、パートナー センターで複数のセキュリティ グループを複数のロールにマップできます。

リソースごとに個別の呼び出しを行います。 1 つの POST 要求を行う場合は、1 つのリソースとそれに対応するスコープのみを渡します。 たとえば、https://graph.windows.net/Directory.AccessAsUser.All と https://graph.microsoft.com/Organization.Read.Allの両方のアクセス許可を要求するには、それぞれ 2 つの異なる要求を行います。

指定されたリンクを使用して、リソース名を検索します。サインイン レポートでファースト パーティの Microsoft アプリケーションを確認する - Active Directory。 たとえば、リソース ID 00000003-0000-0000-c000-0000000000000:graph.microsoft.com:

通常、このエラーは、クエリ フィルターで正しくない識別子が使用されている場合に発生します。 これを解決するには、enterpriseApplicationId プロパティを、リソース名ではなく、正しい リソース IDで使用していることを確認します。

• enterpriseApplicationIdの要求 が正しくありません。graph.microsoft.com などのリソース名は使用しないでください。
• 正しい要求 代わりに、enterpriseApplicationIdの場合は、リソース ID (00000003-0000-0000-c000-0000000000000 など) を使用します。

たとえば、リソース graph.microsoft.com 以前は、"プロファイル" スコープのみが同意されました。 ここで、profile と user.read も追加する必要があります。 以前に同意したアプリケーションに新しいスコープを追加するには:

1. DELETE メソッドを使用して、顧客のテナントから既存のアプリケーションの同意を取り消します。
2. POST メソッドを使用して、追加のスコープで新しいアプリケーションの同意を作成します。

コンマとそれに続くスペースを使用して、必要なスコープを連結します。 たとえば、"scope": "profile, User.Read"

1. 要求本文の 'displayName' プロパティと 'applicationId' プロパティが正確であり、顧客テナントに同意しようとしているアプリケーションと一致していることを確認します。
2. 同じアプリケーションを使用して、顧客テナントに同意しようとしているアクセス トークンを生成していることを確認します。 たとえば、アプリケーション ID が "12341234-1234-1234-12341234" の場合、アクセス トークンの "appId" 要求も "12341234-1234-1234-12341234" にする必要があります。
3. 次のいずれかの条件が満たされていることを確認します。

• アクティブな委任された管理者特権 (DAP) があり、ユーザーはパートナー テナントの管理エージェント セキュリティ グループのメンバーでもあります。
• 次の 3 つの GDAP ロールのうち少なくとも 1 つを持つ Customer テナントとのアクティブな詳細な委任管理者特権 (GDAP) 関係があり、アクセス割り当てを完了しました。
  • グローバル管理者、アプリケーション管理者、またはクラウド アプリケーション管理者ロール。
  • パートナー ユーザーは、アクセス割り当てで指定されたセキュリティ グループのメンバーです。

• 顧客ごとのアクセスパーティション分割 (推奨されるベスト プラクティス) を使用して Azure を管理するには、セキュリティ グループ (Azure Managersなど) を作成し、管理エージェントの下に入れ子 します。
• 顧客の所有者として Azure サブスクリプションにアクセスするには、Microsoft Entra 組み込みロール (ディレクトリ 閲覧者、最小特権ロールなど) を、Azure Managers セキュリティ グループに割り当てることができます。 Azure GDAP を設定する手順については、詳細な委任された管理者特権 (GDAP)でサポートされるワークロード を参照してください。

はい。 Microsoft Entra で最小限の特権ロールを割り当てることでユーザーの管理者権限を制限する方法については、Microsoft Entraのタスク別の最小特権ロールの を参照してください。

サービス サポート管理者 ロールを割り当てることをお勧めします。 詳細については、Microsoft Entraのタスク別の最小特権ロールの を参照してください。

• パートナー センター API と UI で使用できる Microsoft Entra ロール間のギャップを減らすために、2024 年 7 月にパートナー センター UI で 9 つのロールの一覧を利用できます。
• [コラボレーション] の下:
  • Microsoft Edge 管理者
  • 仮想アクセス管理者
  • Viva ゴール管理者
  • Viva Pulse 管理者
  • Yammer 管理者
• [ID] の下:
  • アクセス許可管理管理者
  • ライフサイクル ワークフロー管理者
• [その他] の下:
  • 組織ブランド管理者
  • 組織のメッセージ承認者

いいえ。 パートナー ユーザーが顧客のサポート チケットを作成できる最小限の特権ロールは、サービス サポート管理者です。 そのため、顧客のサポート チケットを作成できるようにするには、パートナー ユーザーがセキュリティ グループに属し、そのロールを持つその顧客に割り当てられている必要があります。

すべてのロールの詳細については、Microsoft Entra 組み込みロールを参照してください。 ワークロードの詳細については、詳細な委任された管理者特権 (GDAP)でサポートされているワークロードの を参照してください。

Microsoft 365 管理センターでは、多くの役割が使用されます。 詳細については、「一般的に使用される Microsoft 365 管理センターの役割を参照してください。

はい。 セキュリティ グループを作成し、承認されたロールを割り当ててから、そのセキュリティ グループにパートナー テナント ユーザーを割り当てます。

顧客のサブスクリプションへの読み取り専用アクセスは、グローバル 閲覧者、ディレクトリ 閲覧者、およびパートナー層 2 が ロールをサポート によって提供されます。

管理エージェントの ロールからパートナー エージェントを削除し、GDAP セキュリティ グループにのみ追加することをお勧めします。 そうすることで、サービス (サービス管理やログ サービス要求など) を管理できますが、サブスクリプションの購入と管理 (数量の変更、取り消し、変更のスケジュールなど) は行えません。

リレーションシップに割り当てられているセキュリティ グループは、その顧客にアクセスできなくなります。 顧客が DAP 関係を終了した場合も同じことが起こります。

はい。 顧客との GDAP 関係を削除しても、パートナーのリセラーと顧客の関係は終了しません。 パートナーは引き続き顧客の製品を購入し、Azure 予算やその他の関連アクティビティを管理できます。

いいえ。 GDAP リレーションシップ内のすべてのロールの有効期限は、リレーションシップの作成時に選択された期間と同じです。

いいえ。 新規および既存の顧客の注文を満たすために GDAP は必要ありません。 引き続き同じプロセスを使用して、パートナー センターで顧客の注文を満たすことができます。

GDAP リレーションシップは顧客ごとに行われます。 顧客ごとに複数のリレーションシップを持つことができます。 各 GDAP リレーションシップは、異なるロールを持ち、CSP テナント内で異なる Microsoft Entra グループを使用できます。 パートナー センターでは、ロールの割り当ては顧客と GDAP の関係レベルで機能します。 マルチカスタム ロールの割り当てを行う場合は、API を使用して自動化できます。

GDAP ゲスト管理者は、My Security-Infoで独自のセキュリティ情報を管理できません。 代わりに、セキュリティ情報の登録、更新、または削除について、ゲストであるテナント管理者の支援が必要です。 組織は、信頼された CSP テナントから MFA を信頼するようにテナント間アクセス ポリシーを構成できます。 それ以外の場合、GDAP ゲスト管理者は、テナント管理者が登録できる方法 (SMS または音声) のみに制限されます。 詳細については、テナント間アクセス ポリシーのに関するページを参照してください。

ゼロ トラストの の基本原則に沿って:最小限の特権アクセス使用します。

• GDAP でサポート 詳細な委任された管理者特権 (GDAP) でサポートされるワークロード 、タスク とワークロード タスクで 最小特権ロールを使用することをお勧めします。
• 一覧表示されている既知の問題を回避する必要がある場合は、顧客と協力して、期限付きのグローバル管理者ロールを要求してください。
• グローバル管理者ロールを Microsoft Entra のすべてのロールに置き換えることをお勧め 。

はい。 移行期間中は、DAP と GDAP が共存し、GDAP アクセス許可は、Microsoft 365、Dynamics 365、および Azure ワークロード の DAP アクセス許可よりも優先されます。

移行期間中は DAP と GDAP が共存します。 しかし、最終的に GDAP は DAP を置き換えて、パートナーと顧客に対してより安全なソリューションを提供します。 継続性を確保するために、できるだけ早く顧客を GDAP に移行することをお勧めします。

DAP と GDAP が共存している間、既存の DAP リレーションシップ フローに変更はありません。

DAP は現在、新しい顧客テナントの作成時に付与されます。 2023 年 9 月 25 日に、Microsoft は新しい顧客作成のために DAP を付与せず、代わりに特定のロールを持つ既定の GDAP を付与します。 次の表に示すように、既定のロールはパートナーの種類によって異なります。

パートナーは、パートナーのテナント内の GDAP セキュリティ グループに Privileged Identity Management (PIM) を実装して、少数の高い特権を持つユーザーのアクセス権を昇格させることができます。Just-In-Time (JIT) では、アクセスの自動削除によるパスワード管理者などの高い特権ロールを付与できます。 2023 年 1 月まで、すべての Privileged Access Group (PIM for Groups 機能の以前の名前) が、ロール割り当て可能な グループに存在する必要がありました。 この制限 削除されました。 この変更により、PIMでテナント ごとに 500 を超えるグループ を有効にできますが、ロール割り当て可能なグループは最大 500 個までです。 概要：

• パートナーは、PIM でロール割り当て可能な グループとロール割り当て不可能な グループの両方を使用できます。 このオプション 、PIM の /tenant500 グループの制限を実質的に削除します。
• 最新の更新プログラムでは、グループ を PIM (UX) にオンボードするには、PIM メニューまたは グループ メニューの 2 つの方法があります。 選択方法に関係なく、ネットの結果は同じです。
  • PIM メニューを使用して、ロール割り当て可能なグループまたはロール割り当て不可能なグループをオンボードする機能は既に利用できます。
  • [グループ] メニューを使用して、ロール割り当て可能なグループまたはロール割り当て不可能なグループをオンボードする機能が既に用意されています。
• 詳細については、「グループの Privileged Identity Management (PIM) (プレビュー) - Microsoft Entra」を参照してください。

GDAP は、すべての Microsoft 商用クラウド サービス (Microsoft 365、Dynamics 365、Microsoft Azure、および Microsoft Power Platform ワークロード ) をサポートして一般提供されています。 DAP と GDAP の共存方法と GDAP の優先順位の詳細については、DAP と GDAP の共存中に GDAP アクセス許可が DAP アクセス許可よりも優先される については、こちらの FAQ を参照してください。 質問。

このアクションは API を使用して実行できます。

いいえ。 GDAP に移行しても PEC の収益は影響を受けません。 移行に伴って PAL に変更はなく、PEC を引き続き獲得できます。

• パートナーの顧客が DAP のみを持っていて、DAP が削除された場合、PEC は失われません。
• パートナーの顧客が DAP を持っていて、Microsoft 365 と Azure の GDAP に同時に移行し、DAP が削除された場合、PEC は失われません。
• パートナーの顧客が DAP を持っていて、Microsoft 365 用の GDAP に移行しても、Azure as-is を保持していて (GDAP に移行しない)、DAP が削除された場合、PEC は失われませんが、Azure サブスクリプションへのアクセスは失われます。
• RBAC ロールが削除されると、PEC は失われますが、GDAP を削除しても RBAC は削除されません。

ユーザーが GDAP セキュリティ グループと DAP 管理エージェント グループ の両方の一部であり、お客様が DAP と GDAP の両方の関係を持つ は、パートナー、顧客、ワークロード レベルで GDAP アクセスが優先されます。

たとえば、パートナー ユーザーがワークロードにサインインし、グローバル管理者ロールの DAP とグローバル閲覧者ロールの GDAP がある場合、パートナー ユーザーはグローバル閲覧者のアクセス許可のみを取得します。

GDAP セキュリティ グループのみに GDAP ロールが割り当てられているお客様が 3 人いる場合 (管理者エージェントは割り当てません)。

次の表では、ユーザーが別の顧客テナントにサインインした場合の動作について説明します。

DAP と GDAP は、ソリューション パートナーの指定の対象となる関連付けの種類ではありません。 aDisabling または DAP から GDAP への移行は、ソリューション パートナーの指定の達成には影響しません。 また、レガシ コンピテンシー特典またはソリューション パートナー特典の更新は影響を受けません。 ソリューション パートナーの指定の対象となる他のパートナー関連付けの種類を表示するには、「パートナー センター ソリューション パートナーの指定 を参照してください。

Azure Lighthouse と DAP/GDAP の関係については、Azure リソースへの分離された並列パスと考えてください。 1 つを切断しても、もう一方には影響しません。

• Azure Lighthouse のシナリオでは、パートナー テナントのユーザーは顧客テナントにサインインせず、顧客テナントに Microsoft Entra アクセス許可がありません。 Azure RBAC ロールの割り当てもパートナー テナントに保持されます。
• GDAP シナリオでは、パートナー テナントのユーザーが顧客テナントにサインインします。 管理エージェント グループへの Azure RBAC ロールの割り当ては、顧客テナントにも含まれます。 Azure Lighthouse パスが影響を受けない間は、GDAP パスをブロックできます (ユーザーはサインインできなくなります)。 逆に、GDAP に影響を与えずに Lighthouse リレーションシップ (プロジェクション) を切断できます。 詳細については、Azure Lighthouse ドキュメント を参照してください。

クラウド ソリューション プロバイダー (CSP) プログラムに間接リセラー または直接請求 として登録されているマネージド サービス プロバイダー (MSP) パートナーは、Microsoft 365 Lighthouse を使用して任意の顧客テナントに GDAP を設定できるようになりました。 パートナーが GDAP への移行を既に管理している方法はいくつかありますが、このウィザードを使用すると、Lighthouse パートナーはビジネス ニーズに固有のロールの推奨事項を採用できます。 また、Just-In-Time (JIT) アクセスなどのセキュリティ対策を採用することもできます。 また、MSP は Lighthouse を通じて GDAP テンプレートを作成して、最小限の特権を持つ顧客アクセスを可能にする設定を簡単に保存して再適用することもできます。 詳細とデモを表示するには、Lighthouse GDAP セットアップ ウィザードのを参照してください。 MSP は、Lighthouse 内の任意の顧客テナントに対して GDAP を設定できます。 Lighthouse で顧客のワークロード データにアクセスするには、GDAP または DAP リレーションシップが必要です。 GDAP と DAP が顧客テナントに共存する場合、GDAP が有効なセキュリティ グループの MSP 技術者には GDAP アクセス許可が優先されます。 Microsoft 365 Lighthouse の要件の詳細については、「Microsoft 365 Lighthouseの 要件」を参照してください。

このシナリオで従う正しい順序は次のとおりです。

1. Microsoft 365 と Azureの両方 の GDAP リレーションシップを作成します。
2. Microsoft 365 と Azureの両方の のセキュリティ グループに Microsoft Entra ロールを割り当てます。
3. DAP よりも優先するように GDAP を構成します。
4. DAP を削除します。

次のシーケンスを実行すると、Azure サブスクリプションへのアクセス が失われることがあります。

1. DAP を削除します。 DAP を削除することで、必ずしも Azure サブスクリプションへのアクセスが失われるわけではありません。 ただし、現時点では、顧客のディレクトリを参照して Azure RBAC ロールの割り当てを実行することはできません (サブスクリプション RBAC 共同作成者として新しい顧客ユーザーを割り当てるなど)。
2. Microsoft 365 と Azure の両方 一緒に GDAP リレーションシップを作成します。 GDAP が設定されるとすぐに、この手順で Azure サブスクリプションにアクセスできなくなる可能性があります。
3. Microsoft 365 と Azure の両方の のセキュリティ グループに Microsoft Entra ロールを割り当てる

Azure GDAP のセットアップが完了すると、Azure サブスクリプションへのアクセスが回復します。

所有者として管理する DAP なしで Azure サブスクリプションを している場合、その顧客に GDAP for Microsoft 365 を追加すると、Azure サブスクリプションへのアクセスが失われる可能性があります。 アクセスの喪失を回避するには、顧客を Microsoft 365 GDAP に移行する と同時に、顧客を Azure GDAP に移動します。

いいえ。 一度受け入れられたリレーションシップは再利用できません。

顧客と既存のリセラー関係がある場合でも、Azure サブスクリプションを管理するには GDAP 関係を確立する必要があります。

1. Microsoft Entra でセキュリティ グループ (Azure マネージャーなど) を作成します。
2. ディレクトリ 閲覧者 ロールを使用して GDAP リレーションシップを作成します。
3. セキュリティ グループを Admin Agent グループのメンバーにします。 これらの手順を実行すると、AOBO を使用して顧客の Azure サブスクリプションを管理できます。 CLI/Powershell を使用してサブスクリプションを管理することはできません。

はい。 既存のリセラー関係を持つ DAP または GDAP がない場合でも、Azure プランを作成できます。 ただし、そのサブスクリプションを管理するには、DAP または GDAP が必要です。

パートナーが DAP から GDAP に移行する場合、会社の詳細を表示するには、次の内容が設定されていることを確認する必要があります。

• アクティブな GDAP リレーションシップ。
• 次のいずれかの Microsoft Entra ロールが割り当てられます:グローバル管理者、ディレクトリ閲覧者、グローバル閲覧者。 セキュリティ グループ に詳細なアクセス許可を付与する方法に関するページを参照してください。

CSP が CSP 資格情報を使用して顧客の Azure portal (portal.azure.come) にログインし、GDAP リレーションシップが存在すると、CSP はユーザー名が "user_" の後に数が続いていることがわかります。 DAP のように実際のユーザー名は表示されません。 仕様です。

パートナーは、既定の GDAP で セキュリティ グループに詳細なアクセス許可を明示的に付与 必要があります。
2023 年 10 月 10 日の時点で、DAP はリセラー関係では使用できなくなりました。 更新された [リセラー関係の要求] リンクはパートナー センター UI で使用でき、API コントラクト "/v1/customers/relationship requests" プロパティ URL は、顧客テナントの管理者に送信される招待 URL を返します。

はい。パートナーは、顧客を管理するために既定の GDAP で セキュリティ グループに詳細なアクセス許可を明示的に付与 必要があります。

DAP または GDAP を使用しないリセラー関係を持つパートナーは、顧客の作成、注文の配置と管理、ソフトウェア キーのダウンロード、Azure RI の管理を行うことができます。 顧客の会社の詳細を表示できない、ユーザーにライセンスを割り当てることができない、顧客に代わってチケットを記録できない、製品固有の管理センターにアクセスして管理できない (Teams 管理センターなど)。

パートナーまたは CPV が顧客テナントにアクセスして管理するには、顧客テナントでアプリのサービス プリンシパルに同意する必要があります。 DAP がアクティブな場合、パートナー テナントの管理エージェント SG にアプリのサービス プリンシパルを追加する必要があります。 GDAP では、パートナーはアプリが顧客テナントで同意されていることを確認する必要があります。 アプリが委任されたアクセス許可 (アプリ + ユーザー) を使用し、アクティブな GDAP が 3 つのロール (クラウド アプリケーション管理者、アプリケーション管理者、グローバル管理者) のいずれかに存在する場合は、同意 API 使用できます。 アプリがアプリケーションのアクセス許可のみを使用する場合は、テナント全体の管理者の同意 URLを使用して、3 つのロール (クラウド アプリケーション管理者、アプリケーション管理者、グローバル管理者) のいずれかを持つパートナーまたは顧客が手動で同意 必要があります。

次のエラーが表示される場合:

"現時点では、'新しい GDAP リレーションシップの作成' 要求を検証できません。 このサービスでは匿名接続が許可されていないことを推奨します。 エラーでこのメッセージが表示されたと思われる場合は、もう一度要求を試してください。 選択すると、実行できるアクションについて学習できます。 問題が解決しない場合は、サポートに問い合わせ、メッセージ コード 715-123220 とトランザクション ID: guid を参照してください。

Microsoft への接続方法を変更して、ID 検証サービスを正常に実行できるようにします。 アカウントが侵害されず、Microsoft が準拠する必要がある規制に準拠していることを確認するのに役立ちます。

できること:

• ブラウザーのキャッシュをクリアします。
• ブラウザーで追跡防止を無効にするか、例外/セーフ リストにサイトを追加します。
• 使用している可能性がある仮想プライベート ネットワーク (VPN) プログラムまたはサービスをオフにします。
• 仮想マシン (VM) 経由ではなく、ローカル デバイスから直接接続します。

前の手順を試しても接続できない場合は、IT ヘルプ デスクに問い合わせて設定を確認し、問題の原因を特定できるかどうかを確認することをお勧めします。 会社のネットワーク設定で問題が発生することがあります。 IT 管理者は、たとえば、サイトを安全に一覧表示したり、他のネットワーク設定を調整したりして、問題に対処する必要があります。

• 制限付き (直接請求): 新しい GDAP (管理者リレーションシップ) を作成できません。 既存の GDAP とそのロールの割り当てを更新できます。
• 中断 (直接請求/間接プロバイダー/間接リセラー): 新しい GDAP を作成できません。 既存の GDP とそのロールの割り当てを更新することはできません。
• 制限付き (直接請求) + アクティブ (間接リセラー): 制限付き直接請求の場合: 新しい GDAP (管理者リレーションシップ) を作成できません。 既存の GDAP とそのロールの割り当てを更新できます。 アクティブ間接リセラーの場合: 新しい GDAP を作成でき、既存の CSP とそのロールの割り当てを更新できます。 オフボードされた新しい GDAP を作成できない場合、既存の GDAP とそのロールの割り当てを更新することはできません。

はい。 GDAP の現在のリリースでは、Microsoft 365、Dynamics 365、Microsoft Power Platform、および Microsoft Azureのすべての製品がサポートされています。