Microsoft Graph API で複数管理承認を使用する

マルチ管理承認 (MAA) は、Microsoft Graph API を介して行われたアプリケーション認証 (app-auth) API 呼び出しに承認ワークフローを適用します。 organization でサービスプリンシパル、オートメーションスクリプト、またはサードパーティ製アプリケーションを使用して Intune リソースを管理する場合、ターゲットリソースがアクセスポリシーによって保護されている場合、それらの呼び出しは MAA によってインターセプトされます。

この記事では、MAA 承認ワークフローと連携するように自動化を更新する方法と、コード変更がすぐに実現できない場合に特定のアプリケーションを施行から除外する方法について説明します。

重要

MAA は、すべてのテナントのワークロードごとにオプトインされます。この適用は、MAA アクセスポリシーが構成されているテナントにのみ適用されます。 MAA を自動的に有効にしたり、MAA を持つテナントを変更したりすることはありません。アクセス・ポリシーの構成について詳しくは、アクセス・ポリシーを使用してマルチ管理者の承認を要求するを参照してください。

アプリ認証呼び出しの変更点

以前は、対話型 (委任された) 管理アクションのみが MAA 承認ワークフローの対象でした。この変更により、ターゲットリソースがアクセスポリシーによって保護されている場合、アプリ専用トークンを使用する自動呼び出しとスクリプト化された呼び出しも MAA によってインターセプトされます。

アプリケーションが app-auth を使用して MAA で保護されたリソースに API 呼び出しを行い、必要な承認ヘッダーが含まれていない場合、呼び出しによって HTTP 400 エラーが返されます。応答本文には、操作にマルチ管理の承認が必要であることが示されています。

影響を受けるリソースの種類

MAA アクセスポリシーは、次のリソースの種類を保護できます。アプリ認証呼び出しがこれらのリソースのいずれかを対象とし、アクセスポリシーがアクティブな場合、自動化が影響を受けます。

アプリ
コンプライアンスポリシー
構成ポリシー
デバイスアクション
役割ベースのアクセス制御
スクリプト
テナントの構成

MAA は、保護されたリソース (POST、PATCH、PUT、DELETE) を変更する操作にのみ適用されます。読み取り専用操作 (GET) は影響を受けません。

前提条件

アプリが管理するIntuneリソース (DeviceManagementApps.ReadWrite.Allなど) に必要な Microsoft Graph アプリケーションのアクセス許可を持つアプリの登録。
関連するワークロードに対して構成された MAA アクセスポリシー。詳細については、「アクセスポリシーの作成」を参照してください。
アクセスポリシーの承認者グループのメンバーである別の管理者アカウント。アプリケーションは MAA 要求を承認または拒否できません。対話型管理者アカウントのみが要求を承認できます。

手順 1: 正当な理由ヘッダーを含む要求を送信する

MAA が有効になっている場合は、要求に Justification ヘッダーを含めます。 x-msft-approval-justification ヘッダー値は Base64 でエンコードする必要があります。

次の例では、Intune で PowerShell スクリプトリソースを作成し、必要な justification ヘッダーを含めます。

POST https://graph.microsoft.com/beta/deviceManagement/deviceManagementScripts
Content-Type: application/json
x-msft-approval-justification: YXBwIG9ubHkgdGVzdA==

{
  "displayName": "My Test Script",
  "description": "Testing MAA with app-only token",
  "scriptContent": "V3JpdGUtT3V0cHV0ICJIZWxsbyBXb3JsZCI=",
  "runAsAccount": "system",
  "fileName": "TestScript.ps1",
  "roleScopeTagIds": ["0"]
}

ヒント

x-msft-approval-justification値は Base64 でエンコードされます。たとえば、 YXBwIG9ubHkgdGVzdA== は app only test にデコードします。送信する前に、独自の正当な理由文字列をエンコードします。

Justification ヘッダーがないと、要求は失敗し、 x-msft-approval-justification ヘッダーが必要であることを示すエラーが返されます。

手順 2: 承認応答を処理する

要求により、外部 Microsoft Graph エラーコードが BadRequest の HTTP 412 (Precondition Failed) が返されます。この応答は想定されるものであり、アクセス許可の問題を示すものではありません。MAA が要求を受信し、現在承認を待っていることを通知する方法です。承認が必要な詳細は、エラーメッセージにネストされています。

応答には、残りの手順に必要な x-msft-approval-code ヘッダーが含まれます。このヘッダーの存在と HTTP 412 を共に使用すれば、MAA が要求を受け入れ、承認要求を作成したことを示すシグナルとして使用します。

応答の例:

HTTP/1.1 412 Precondition Failed
x-msft-approval-code: aabb1234-5678-9012-abcd-ef0123456789
Content-Type: application/json

{
  "error": {
    "code": "BadRequest",
    "message": "{\r\n  \"_version\": 3,\r\n  \"Message\": \"Approval Required. Request Approval using the request ID returned as part of the x-msft-approval-code response header. x-msft-approval-code: aabb1234-5678-9012-abcd-ef0123456789 - Operation ID (for customer support): 00000000-0000-0000-0000-000000000000 - Activity ID: <activity-id> - Url: <service-url>\",\r\n  \"CustomApiErrorPhrase\": \"\",\r\n  \"RetryAfter\": null,\r\n  \"ErrorSourceService\": \"\",\r\n  \"HttpHeaders\": \"{\\\"x-msft-approval-code\\\":\\\"aabb1234-5678-9012-abcd-ef0123456789\\\"}\"\r\n}"
  }
}

応答から x-msft-approval-code 値を抽出します。承認後に手順 4 で同じ要求を再送信する必要があるため、元の HTTP メソッド、URL、および要求本文をこの値で保存します。

手順 3: 承認を待つ

この時点で、承認要求は、Microsoft Intune 管理センターの別の管理者によって確認および承認される必要があります。アプリケーションは MAA 要求を承認または拒否できません。対話型管理者アカウントのみが承認できます。

承認要求の状態は、承認コードを使用していつでもクエリできます。

GET https://graph.microsoft.com/beta/deviceManagement/operationApprovalRequests?$filter=requestId eq 'aabb1234-5678-9012-abcd-ef0123456789'

status フィールドには、要求の現在の状態が表示されます。一般的な値には、 needsApproval、 approved、 rejected、および cancelled が含まれます。状態が approved に変わるまで待ってから、次に進みます。

手順 4: 承認コードを使用して再送信する

要求が承認されたら、元の要求を再送信します。 Justification ヘッダーを x-msft-approval-code ヘッダーに置き換え、手順 2 の承認コードを使用します。

POST https://graph.microsoft.com/beta/deviceManagement/deviceManagementScripts
Content-Type: application/json
x-msft-approval-code: aabb1234-5678-9012-abcd-ef0123456789

{
  "displayName": "My Test Script",
  "description": "Testing MAA with app-only token",
  "scriptContent": "V3JpdGUtT3V0cHV0ICJIZWxsbyBXb3JsZCI=",
  "runAsAccount": "system",
  "fileName": "TestScript.ps1",
  "roleScopeTagIds": ["0"]
}

要求は正常に完了し、リソースが作成されます。

MAA 適用からアプリケーションを除外する

承認ワークフローを含めるようにアプリケーションをすぐに更新できない場合は、アクセスポリシーの MAA 適用から除外できます。除外を構成するには、アプリが呼び出すワークロードのアクセスポリシーを編集し、[ 除外 ] タブでアプリケーションを追加します。除外が有効になる前に、2 人目の管理者が変更を承認する必要があります。

除外は、除外されたサービスプリンシパルによって行われたアプリ認証 (アプリケーション認証) 呼び出しにのみ適用されます。同じ保護されたリソースに対する対話型 (委任) 管理アクションには、引き続き MAA 承認が必要です。

スコープ、制限、セキュリティ上の考慮事項など、除外の詳細については、「アクセスポリシーの作成」を参照してください。

アプリ認証呼び出しの MAA アクティビティを監視する

MAA 関連のイベント (承認、ブロック、合格、除外の追加、除外の削除など) は、既存の Intune 監査ログに記録されます。標準の監査ログと Graph API エクスポートを使用して、MAA を通過しているアプリ認証呼び出しとその処理方法を確認します。

よく寄せられる質問

オートメーションスクリプトが失敗するのはなぜですか?

オートメーションが Microsoft Graph を呼び出し、MAA アクセスポリシーによって保護されたリソースをターゲットにする場合、スクリプトが代理認証を使用するかアプリのみ認証を使用するかに関係なく、それらの呼び出しは MAA 承認ワークフローによってインターセプトされます。この記事で説明する正当理由ヘッダーと承認ヘッダーを含めるようにスクリプトを更新します。スクリプトでアプリ専用トークン (クライアント資格情報フロー) を使用する場合は、アクセスポリシーからアプリケーションを除外することもできます。

MAA は読み取り専用 API 呼び出しに影響しますか?

その必要はありません。 MAA は、保護されたリソース (POST、PATCH、PUT、DELETE) を変更する操作にのみ適用されます。 GET 要求は影響を受けません。

アプリケーションは独自の MAA 要求を承認できますか。

その必要はありません。アプリケーションは、MAA 要求を承認または拒否できません。承認者グループのメンバーである別の対話型管理者アカウントは、Microsoft Intune 管理センターで要求を承認する必要があります。

テナントで MAA が有効になっている場合は操作方法チェックしますか?

Microsoft Intune 管理センターで、[テナント管理]>マルチ管理の承認>アクセスポリシー] に移動します。アクティブなアクセスポリシーが一覧に表示されている場合は、それらのワークロードに対して MAA が有効になっています。

MAA をオフにして強制を停止できますか?

MAA アクセスポリシーは、適切なアクセス許可を持つ管理者が管理できます。ただし、Microsoft では、セキュリティのベストプラクティスとして MAA を有効にしておくことを強くお勧めします。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-12