概要
このドキュメントでは、インバウンド プロビジョニング API で発生する一般的なエラーや問題とそのトラブルシューティング方法について説明します。
トラブルシューティングのシナリオ
データ形式が無効です
問題の説明
- HTTP 400 (Bad Request) 応答コードで
Invalid Data Formatエラー メッセージを受信しました。
考えられる原因
- プロビジョニング /bulkUpload API 仕様に従って有効な一括要求が送信されていますが、HTTP 要求ヘッダー 'Content-Type' が
application/scim+jsonに設定されていません。 - プロビジョニング /bulkUpload API 仕様に準拠していない一括要求が送信されています。
解決方法:
- HTTP 要求のヘッダー
Content-Typeの値がapplication/scim+jsonに設定されていることを確認します。 - 一括要求ペイロードがプロビジョニング /bulkUpload API 仕様に準拠していることを確認します。
プロビジョニング ログが空である
問題の説明
- プロビジョニング /bulkUpload API エンドポイントに要求を送信し、HTTP 202 応答コードを取得しましたが、要求に対応するデータがプロビジョニング ログにありません。
考えられる原因
- API 駆動型プロビジョニング アプリが一時停止しています。
- プロビジョニング サービスは、プロビジョニング ログに対して一括要求処理の詳細での更新をまだ行っていません。
- オンプレミス プロビジョニング エージェントの状態は非アクティブです ( /API 駆動型のオンプレミス Active Directory への受信ユーザー プロビジョニングを実行している場合)。
解決方法:
- プロビジョニング アプリが実行されていることを確認します。 実行されていない場合は、メニュー オプション [プロビジョニングの開始] を選択してデータを処理します。
- オンプレミス エージェントを再起動して、オンプレミス プロビジョニング エージェントの状態をアクティブにします。
- 要求の処理とプロビジョニング ログへの書き込みの間に 5 分から 10 分の遅延が予想されます。 API クライアントがプロビジョニング /bulkUpload API エンドポイントにデータを送信している場合は、要求呼び出しとプロビジョニング ログ クエリの間に時間の遅延を設けるようにします。
禁止 403 の応答コード
問題の説明
- プロビジョニング /bulkUpload API エンドポイントに要求を送信し、HTTP 403 (禁止) 応答コードを受信しました。
考えられる原因
- Graph アクセス許可
SynchronizationData-User.Uploadが API クライアントに割り当てられません。
解決方法:
- API クライアントに Graph アクセス許可
SynchronizationData-User.Uploadを割り当て、操作を再試行します。
要求が多すぎます 429 の応答コード
bulkUpload API エンドポイントは、次のスロットリング制限を適用し、これらの制限を超えた場合は 429 応答コードを返します。
5 秒あたり 40 回の API 呼び出し – 5 秒間の範囲内で呼び出し回数がこの制限を超えると、クライアントは 429 応答を受け取ります。 これを回避する 1 つの方法は、クライアント要求の送信ロジックで遅延を使用して要求の送信の "ペースを調整する" ことです。
24 時間にわたって 6,000 回の API 呼び出し - 呼び出しの数がこの制限を超えた場合、クライアントは 429 応答を受け取ります。 これを防ぐ 1 つの方法は、SCIM バルク ペイロードが API 呼び出しごとに最大 50 件のレコードを使用するように最適化されていることを確認することです。 この方法では、24 時間ごとに 300,000 件のレコードを送信できます。
未承認 401 の応答コード
問題の説明
- プロビジョニング /bulkUpload API エンドポイントに要求を送信し、HTTP 401 (未承認) 応答コードを受信しました。 エラー コードには、「InvalidAuthenticationToken」と表示され、「アクセス トークンの有効期限が切れているか、まだ有効ではありません」というメッセージが表示されます。
考えられる原因
- アクセス トークンの有効期限が切れています。
解決方法:
- API クライアントの新しいアクセス トークンを生成します。
ジョブが検疫状態になる
問題の説明
- プロビジョニング アプリを開始したばかりで、アプリが検疫状態です。
考えられる原因
- ジョブを開始する前に、通知用メールの設定が行われていません。
解決策: [プロビジョニングの編集] メニュー項目に移動します。 [設定] の [エラーが発生したときにメール通知を送信します] の横にチェックボックスがあり、通知用メールを入力するフィールドがあります。 チェック ボックスをオンにして、メール アドレスを入力し、変更を保存してください。 [プロビジョニングの再開] をクリックして、ジョブを検疫から除外します。
ユーザーの作成 - 無効な UPN
問題の説明 ユーザー プロビジョニング エラーが発生しました。 プロビジョニング ログには、エラー コード AzureActiveDirectoryInvalidUserPrincipalName が表示されます。
解決方法:
- [属性マッピングの編集] ページに移動します。
UserPrincipalNameマッピングを選択し、RandomString関数を使用するように更新します。- 次の式をコピーして式ボックスに貼り付けます。
Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())
この式は、Microsoft Entra ID で受け入れられる UPN 値に乱数を追加することで問題を修正します。
ユーザーの作成に失敗しました - 無効なドメイン
問題の説明 ユーザー プロビジョニング エラーが発生しました。 プロビジョニング ログには、___domain does not exist というエラー メッセージが表示されます。
解決方法:
- [属性マッピングの編集] ページに移動します。
UserPrincipalNameマッピングを選択し、次の式をコピーして式の入力ボックスに貼り付けます。Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())
この式は、Microsoft Entra ID で受け入れられる UPN 値に既定のドメインを追加することで問題を修正します。