インバウンド プロビジョニング API 問題の解決

はじめに

このドキュメントでは、インバウンド プロビジョニング API で発生する一般的なエラーと問題とそのトラブルシューティング方法について説明します。

トラブルシューティングのシナリオ

無効なデータ形式

問題の説明

• HTTP 400 (Bad Request) 応答コードと Invalid Data Format エラー メッセージを受信しました。

考えられる原因

1. プロビジョニング /bulkUpload API 仕様に従って有効な一括要求を送信していますが、HTTP 要求ヘッダー 'Content-Type' を application/scim+json に設定していません。
2. プロビジョニング /bulkUpload API 仕様に準拠していない一括要求を送信しています。

解決策:

1. HTTP 要求のヘッダー Content-Type の値が application/scim+json に設定されていることを確認します。
2. 一括要求ペイロードがプロビジョニング /bulkUpload API 仕様に準拠していることを確認します。

プロビジョニング ログが空である

問題の説明

• プロビジョニング /bulkUpload API エンドポイントに要求を送信し、HTTP 202 応答コードを取得しましたが、要求に対応するデータがプロビジョニング ログにありません。

考えられる原因

1. API 駆動型プロビジョニング アプリが一時停止しています。
2. プロビジョニング サービスは、プロビジョニング ログに対する一括要求処理の詳細での更新をまだ行っていません。
3. オンプレミス プロビジョニング エージェントの状態が非アクティブです (オンプレミスの Active Directory への /API 駆動型受信ユーザー プロビジョニングを実行している場合)。

解決策:

1. プロビジョニング アプリが実行されていることを確認します。 実行されていない場合は、メニュー オプション [プロビジョニングの開始] を選択してデータを処理します。
2. オンプレミス プロビジョニング エージェントの状態をアクティブにするには、オンプレミス エージェントを再起動してください。
3. 要求の処理からプロビジョニング ログへの書き込みまでに 5 分から 10 分の遅延が予想されます。 API クライアントがプロビジョニング /bulkUpload API エンドポイントにデータを送信している場合は、要求呼び出しとプロビジョニング ログ クエリの間に時間の遅延を設けるようにします。

Forbidden 403 応答コード

要求が多すぎます 429 応答コード

bulkUpload API エンドポイントは、次のスロットリング制限を適用し、これらの制限を超えた場合は 429 応答コードを返します。

• 5 秒あたり 40 回の API 呼び出し – 呼び出し回数が 5 秒の範囲内でこの制限を超えると、クライアントは 429 応答を受け取ります。 これを回避する 1 つの方法は、クライアント要求の送信ロジックで遅延を使用して要求の送信の "ペースを調整する" ことです。 

• 24 時間で 6000 回の API 呼び出し – 呼び出し回数がこの制限を超えると、クライアントは 429 応答を受け取ります。 これを防ぐ 1 つの方法は、SCIM バルク ペイロードが API 呼び出しごとに最大 50 件のレコードを使用するように最適化されていることを確認することです。 この方法では、24 時間ごとに 300,000 件のレコードを送信できます。

問題の説明

• プロビジョニング /bulkUpload API エンドポイントに要求を送信し、HTTP 403 (Forbidden) 応答コードを受信しました。

考えられる原因

• Graph アクセス許可 SynchronizationData-User.Upload が API クライアントに割り当てられていません。

解決策:

• API クライアントに Graph アクセス許可 SynchronizationData-User.Upload を割り当て、操作を再試行します。

Unauthorized 401 応答コード

問題の説明

• プロビジョニング /bulkUpload API エンドポイントに要求を送信し、HTTP 401 (Unauthorized) 応答コードを受信しました。 エラー コードには、"InvalidAuthenticationToken" と表示され、"アクセス トークンの有効期限が切れているか、まだ有効ではありません" というメッセージが表示されます。

考えられる原因

• アクセス トークンの有効期限が切れています。

解決策:

• API クライアントの新しいアクセス トークンを生成します。

ジョブが検疫状態になる

問題の説明

• プロビジョニング アプリを開始したばかりで、アプリが検疫状態です。

考えられる原因

• ジョブを開始する前に通知用メールを設定していません。

解決策:[プロビジョニングの編集] メニュー項目に移動します。 [設定] の [エラーの発生時に電子メール通知を送信する] の横にチェックボックスがあり、通知用メールを入力するフィールドがあります。 ボックスをチェックし、電子メールを入力し、変更を保存してください。 [プロビジョニングの再起動 ] をクリックして、ジョブの検疫を解除します。

ユーザーの作成 - UPN が無効です

問題の説明 ユーザー プロビジョニング エラーが発生しました。 プロビジョニング ログは、AzureActiveDirectoryInvalidUserPrincipalName というエラー コードを表示します。

解決策:

1. [属性マッピングの編集] ページに移動します。
2. UserPrincipalName マッピングを選択し、RandomString 関数を使用するように更新します。
3. 次の式をコピーして式ボックスに貼り付けます。 Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

この式は、Microsoft Entra ID で受け入れられる UPN 値に乱数を追加することで問題を修正します。

ユーザーの作成に失敗しました - ドメインが無効です

問題の説明 ユーザー プロビジョニング エラーが発生しました。 プロビジョニング ログには、domain does not exist というエラー メッセージが表示されます。

解決策:

1. [属性マッピングの編集] ページに移動します。
2. UserPrincipalName マッピングを選択し、次の式をコピーして式の入力ボックスに貼り付けます。Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

この式は、Microsoft Entra ID で受け入れられる UPN 値に既定のドメインを追加して問題を修正します。

次のステップ

• インバウンド プロビジョニング API に関する詳細情報