インバウンド プロビジョニング API 問題の解決
はじめに
このドキュメントでは、インバウンド プロビジョニング 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 駆動型プロビジョニング アプリが一時停止しています。
- プロビジョニング サービスは、プロビジョニング ログに対する一括要求処理の詳細での更新をまだ行っていません。
- オンプレミス プロビジョニング エージェントの状態が非アクティブです (オンプレミスの Active Directory への /API 駆動型受信ユーザー プロビジョニングを実行している場合)。
解決策:
- プロビジョニング アプリが実行されていることを確認します。 実行されていない場合は、メニュー オプション [プロビジョニングの開始] を選択してデータを処理します。
- オンプレミス プロビジョニング エージェントの状態をアクティブにするには、オンプレミス エージェントを再起動してください。
- 要求の処理からプロビジョニング ログへの書き込みまでに 5 分から 10 分の遅延が予想されます。 API クライアントがプロビジョニング /bulkUpload API エンドポイントにデータを送信している場合は、要求呼び出しとプロビジョニング ログ クエリの間に時間の遅延を設けるようにします。
Forbidden 403 応答コード
問題の説明
- プロビジョニング /bulkUpload API エンドポイントに要求を送信し、HTTP 403 (Forbidden) 応答コードを受信しました。
考えられる原因
- Graph アクセス許可
SynchronizationData-User.Uploadが API クライアントに割り当てられていません。
解決策:
- API クライアントに Graph アクセス許可
SynchronizationData-User.Uploadを割り当て、操作を再試行します。
要求が多すぎます 429 応答コード
bulkUpload API エンドポイントは、次のスロットリング制限を適用し、これらの制限を超えた場合は 429 応答コードを返します。
5 秒あたり 40 回の API 呼び出し – 呼び出し回数が 5 秒の範囲内でこの制限を超えると、クライアントは 429 応答を受け取ります。 これを回避する 1 つの方法は、クライアント要求の送信ロジックで遅延を使用して要求の送信の "ペースを調整する" ことです。
24 時間で 6000 回の API 呼び出し – 呼び出し回数がこの制限を超えると、クライアントは 429 応答を受け取ります。 これを防ぐ 1 つの方法は、SCIM バルク ペイロードが API 呼び出しごとに最大 50 件のレコードを使用するように最適化されていることを確認することです。 この方法では、24 時間ごとに 300,000 件のレコードを送信できます。
Unauthorized 401 応答コード
問題の説明
- プロビジョニング /bulkUpload API エンドポイントに要求を送信し、HTTP 401 (Unauthorized) 応答コードを受信しました。 エラー コードには、"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 値に既定のドメインを追加して問題を修正します。