次の方法で共有

検疫状態のアプリケーションのプロビジョニング

  • [アーティクル]

Microsoft Entra プロビジョニング サービスは、構成の正常性を監視します。 また、異常なアプリを "検疫" 状態にします。 ターゲット システムに対する呼び出しのほとんどまたはすべてが常に失敗する場合、プロビジョニング ジョブは検疫状態になります。 失敗の例としては、無効な管理者資格情報が原因で受け取るエラーがあります。

検疫中は、次のようになります。

  • 増分サイクルの頻度は徐々に減少し、最終的には 1 日 1 回になります。
  • すべてのエラーが修正されると、プロビジョニング ジョブは検疫から削除され、次の同期サイクルが開始します。
  • プロビジョニング ジョブが検疫にとどまっている期間が 4 週間を超えると、そのプロビジョニング ジョブは無効 (実行が停止) になります。

アプリケーションが検疫されているかどうかを確認するにはどうすればよいですか。

アプリケーションが検疫中かどうかを確認するには、次の 3 つの方法があります。

  • Microsoft Entra 管理センターで、[ID]>[アプリケーション]>[エンタープライズ アプリケーション]><[アプリケーション名]>>[プロビジョニング] の順に移動し、検疫メッセージの進行状況バーを確認します。

    検疫状態を示すプロビジョニング ステータス バー

  • Microsoft Entra 管理センターで、[アクティビティ: 検疫] の [ID]>[監視と正常性]>[監査ログ]> フィルターに移動し、検疫履歴を確認します。 前に説明した進行状況バーのビューは、プロビジョニングが現在検疫中かどうかを示しています。 監査ログには、アプリケーションの検疫履歴が表示されます。

  • Microsoft Graph 要求の Get synchronizationJob を使用して、プロビジョニング ジョブの状態をプログラムで取得します。

        GET https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/

  • メールを確認します。 アプリケーションが検疫されると、1 回限りの通知メールが送信されます。 検疫の理由が変化した場合、新しい検疫理由を示す更新されたメールが送信されます。 メールが送信されない場合は、次を確認します。

    • アプリケーションのプロビジョニング構成で有効な通知メールを指定していることを確認します。
    • 通知メールの受信トレイにスパム フィルターが適用されていないことを確認します。
    • メールの登録を解除していないことを確認します。
    • azure-noreply@microsoft.com からの電子メールを確認します。

アプリケーションが検疫されているのはなぜですか。

アプリケーションが検疫に入れられる一般的な理由を次に示します

説明 推奨される操作
SCIM へのコンプライアンスの問題: 予期される HTTP/200 OK 応答ではなく、HTTP/404 Not Found 応答が返されました。 この場合、Microsoft Entra プロビジョニング サービスによってターゲット アプリケーションへの要求が行われ、予期しない応答を受け取りました。 管理者資格情報のセクションを確認します。 アプリケーションでテナントの URL を指定する必要があるかどうか、および URL が正しいことを確認します。 問題が見つからない場合は、アプリケーションの開発者に連絡し、サービスが SCIM に準拠していることを確認してください。 https://tools.ietf.org/html/rfc7644#section-3.4.2
無効な資格情報: ターゲット アプリケーションへのアクセスの承認を試みたとき、指定された資格情報が無効であることを示す応答をターゲット アプリケーションから受け取りました。 プロビジョニング構成 UI の管理者資格情報セクションに移動し、有効な資格情報で再度アクセスを承認してください。 アプリケーションがギャラリーにある場合は、アプリケーション構成のチュートリアルで追加の手順を確認してください。
重複したロール: Salesforce や Zendesk などの特定のアプリケーションからインポートされるロールは、一意である必要があります。 Microsoft Entra 管理センターでアプリケーションのマニフェストに移動し、重複するロールを削除します。

プロビジョニング ジョブの状態を取得するための Microsoft Graph 要求では、次の検疫理由が示されます。

  • EncounteredQuarantineException は、無効な資格情報が指定されたことを示します。 プロビジョニング サービスは、ソース システムとターゲット システム間の接続を確立できません。
  • EncounteredEscrowProportionThreshold は、プロビジョニングがエスクローのしきい値を超えたことを示します。 この状態は、40% 以上のプロビジョニング イベントが失敗すると発生します。 詳細については、エスクローのしきい値の詳細を以下で確認してください。
  • QuarantineOnDemand は、アプリケーションの問題を検出し、検疫するよう手動で設定したことを意味します。

エスクローのしきい値

エスクローの相応なしきい値に達した場合、プロビジョニング ジョブは検疫に入ります。 このロジックは変更される可能性がありますが、ほぼ次のように動作します。

ジョブは、管理者の資格情報や SCIM コンプライアンスなどのイシューの失敗数に関係なく、検疫に入ることがあります。 ただし、一般に、失敗が多いことが原因での検疫を行うかどうかの評価を開始するには、最低でも 5,000 の失敗が必要です。 たとえば、4,000 の失敗が発生したジョブは検疫に入りません。 しかし、5,000 の失敗が発生したジョブでは、評価がトリガーされます。 評価では、次の条件が使用されます。

  • プロビジョニング イベントの 40% が失敗した場合、または 40,000 個を超える失敗が発生した場合、プロビジョニング ジョブは検疫に入ります。 参照の失敗は、40% のしきい値または 40,000 のしきい値の一部としてカウントされません。 たとえば、マネージャーまたはグループ メンバーの更新の失敗は、参照の失敗です。
  • 45,000 人のユーザーが正常にプロビジョニングされなかったジョブは、40,000 のしきい値を超えているため、検疫に入ります。
  • 30,000 人のユーザーがプロビジョニングに失敗し、5,000 人は正常に完了したジョブは、40% のしきい値と 5,000 の最小値を超えているため、検疫に入ります。
  • 20,000 の失敗が発生し、100,000 が成功したジョブは、40% の失敗のしきい値または 40,000 の失敗の最大値を超えていないため、検疫に入りません。
  • 参照と非参照の両方の失敗から成る、60,000 の失敗の絶対しきい値があります。 たとえば、40,000 人のユーザーのプロビジョニングに失敗し、21,000 人のマネージャーの更新が失敗したとします。 失敗の合計は 61,000 であり、60,000 の制限を超えています。

再試行期間

ここに記載されているロジックは、最高のカスタマー エクスペリエンスを保証するために特定のコネクタで異なる場合がありますが、通常の失敗後の再試行サイクルは次のとおりです。

1 回目の再試行は、失敗の 6 時間後に行われます。

  • 2 回目の再試行は、最初の失敗の 12 時間後に行われます。
  • 3 回目の再試行は、最初の失敗の 24 時間後に行われます。

3 回目の再試行から 24 時間ごとに再試行が行われます。 再試行は、最初のエラーの後、エスクロー エントリが削除され、ジョブが無効になってから 28 日間続きます。
上記のいずれかの再試行が成功した場合、ジョブは自動的に検疫から除外され、通常の同期動作を再開します。

アプリケーションを検疫しないよう設定するにはどうすればよいですか。

まず、アプリケーションが検疫される原因となった問題を解決します。

  • アプリケーションのプロビジョニング設定を調べ、有効な管理者の資格情報が入力されていることを確認してください。 Microsoft Entra ID は、ターゲット アプリケーションとの信頼関係を確立する必要があります。 有効な資格情報を入力し、アカウントに必要なアクセス許可があることを確認します。

  • プロビジョニング ログを確認して、検疫の原因となっているエラーを詳しく調査し、解決します。 [Microsoft Entra ID]>[エンタープライズ アプリ]>[プロビジョニング ログ] ([アクティビティ] セクション内) に移動します。

問題を解決したら、プロビジョニング ジョブを再開します。 属性マッピングやスコープフィルターなど、アプリケーションのプロビジョニング設定に特定の変更を加えると、自動的にプロビジョニングが再開されます。 アプリケーションの [プロビジョニング] ページの進行状況バーは、プロビジョニングが最後に開始された日時を示します。 プロビジョニング ジョブを手動で再起動する必要がある場合は、次のいずれかの方法を使用します。

  • Microsoft Entra 管理センターを使用して、プロビジョニング ジョブを再起動します。 アプリケーションのプロビジョニングページで、プロビジョニングを再開するを選択します。 この操作により、プロビジョニング サービスが完全に再起動されます (しばらく時間がかかることがあります)。 すべての初回サイクルが再度実行されます。これにより、エスクローがクリアされ、アプリが検疫から削除され、透かしがクリアされます。 このサービスでは、ソース システム内のすべてのユーザーを再度評価し、プロビジョニングの対象になっているかどうかを判断します。 これは、この記事で説明されているように、アプリケーションが現在検査中である場合や、属性マッピングを変更する必要がある場合に便利です。 初期サイクルは、評価が必要なオブジェクトの数が多いため、通常の増分サイクルよりも完了までに時間がかかることに注意してください。 初期サイクルと増分サイクルのパフォーマンスの詳細については、こちらを参照してください。

  • Microsoft Graph を使用して、プロビジョニング ジョブを再起動します。 再起動する対象は完全に制御できます。 エスクローをクリアするか (検疫状態と判定されるためのエスクロー カウンターを再起動するため)、検疫をオフにするか (検疫からアプリケーションを削除するため)、または透かしをクリアするかを選択できます。 次の要求を使用します。

        POST /servicePrincipals/{id}/synchronization/jobs/{jobId}/restart

"{Id}" をアプリケーション ID の値に置き換え、"{jobId}" を同期ジョブの ID に置き換えます。