数秒でユーザーまたはグループをプロビジョニングするには、オンデマンド プロビジョニングを使用します。 この機能を使用すると、特に以下のことが可能です。
- 構成の問題を迅速にトラブルシューティングする。
- 定義した式を検証する。
- スコープ フィルターをテストする。
オンデマンド プロビジョニングの使用方法
- Microsoft Entra 管理センターに、少なくともアプリケーション管理者としてサインインします。
- Entra ID>Enterprise アプリに移動し>アプリケーションを選択します。
- プロビジョニングを選択します。
- Entra ID>外部ID>テナント間同期>構成 に移動します
- 構成を選択し、[ プロビジョニング の構成] ページに移動します。
管理者の資格情報を指定してプロビジョニングを構成します。
オンデマンドでプロビジョニングを選択します。
名、姓、表示名、ユーザー プリンシパル名、またはメール アドレスでユーザーを検索します。 または、グループを検索し、最大 5 人のユーザーを選択することもできます。
注
クラウド人事プロビジョニング アプリ (Workday/SuccessFactors から Active Directory/Microsoft Entra ID) の場合、入力値は異なります。 Workday のシナリオの場合は、Workday でのユーザーの "WorkerID" または "WID" を指定してください。 SuccessFactors のシナリオの場合は、SuccessFactors でのユーザーの "personIdExternal" を指定してください。
ページの下部にある [ プロビジョニング ] を選択します。
プロビジョニングの手順について
ユーザーをプロビジョニングするときには、オンデマンド プロビジョニング プロセスによって、プロビジョニング サービスで実行される手順の表示が試みられます。 ユーザーをプロビジョニングする手順は、通常は 5 つあります。 オンデマンド プロビジョニング エクスペリエンスの間には、以降のセクションで説明する手順のうち、1 つ以上が表示されます。
手順 1:接続テスト
プロビジョニング サービスにより、"テスト ユーザー" に対する要求が作成され、ターゲット システムへのアクセスの承認が試みられます。 プロビジョニング サービスでは、サービスがプロビジョニング手順の続行を承認したことを示す応答が想定されています。 このステップは、失敗時にのみ表示されます。 手順が成功した場合は、オンデマンド プロビジョニング エクスペリエンスの間に表示されません。
トラブルシューティングのヒント
- ターゲット システムに対して、シークレット トークンやテナント URL などの有効な資格情報を指定したことを確認します。 必要な資格情報はアプリケーションによって異なります。 詳細な構成チュートリアルについては、チュートリアルの 一覧を参照してください。
- ターゲット システムで、[ 属性マッピング ] ウィンドウで定義されている一致する属性のフィルター処理がサポートされていることを確認します。 サポートされているフィルターを知るために、アプリケーション開発者によって提供される API ドキュメントを調べる必要が生じることがあります。
- クロスドメイン ID 管理システム (SCIM) アプリケーションの場合は、cURL などの REST API ツールを使用できます。 このようなツールは、認証要求に対して、Microsoft Entra プロビジョニング サービスで予期される方法で確実にアプリケーションを応答させるのに役立ちます。 要求の例を見てみましょう。
手順 2:ユーザーをインポートする
次に、プロビジョニング サービスにより、ソース システムからユーザーが取得されます。 サービスが取得するユーザー属性は、以下のために後で使用されます。
- ユーザーがプロビジョニングのスコープ内にあるかどうかを評価します。
- 既存のユーザーがいないかターゲット システムを調べます。
- ターゲット システムにどのユーザー属性をエクスポートするかを決定します。
詳細を表示する
[ 詳細の表示] セクションには、ソース システムからインポートされたユーザーのプロパティ (Microsoft Entra ID など) が表示されます。
トラブルシューティングのヒント
ソース システム内のユーザー オブジェクトに一致する属性がない場合、ユーザーのインポートは失敗する可能性があります。 このエラーを解決するには、以下のいずれかの方法を試してください。
- 一致している属性の値を使用して、ユーザー オブジェクトを更新します。
- プロビジョニングの構成で、一致する属性を変更します。
インポートされた一覧に、予期した属性がない場合は、ソース システムのユーザー オブジェクトで、属性に値があることを確認します。 プロビジョニング サービスでは、現在、null 属性のプロビジョニングはサポートされていません。
プロビジョニング構成の [属性マッピング ] ページに、想定される属性が含まれていることを確認します。
手順 3:ユーザーがスコープ内にあるかどうかを確認する
次に、プロビジョニング サービスは、ユーザーがプロビジョニングの スコープ 内にあるかどうかを判断します。 サービスによって考慮されるのは以下のような側面です。
- ユーザーがアプリケーションに割り当てられているかどうか。
- スコープが [ 割り当てられた同期 ] または [ すべて同期] に設定されているかどうか。
- プロビジョニング構成で定義されているスコープ フィルター。
詳細を表示する
[ 詳細の表示] セクションには、評価されたスコープ条件が表示されます。 以下のプロパティのうち、1 つまたは複数が表示される可能性があります。
-
ソース システムでアクティブ は、ユーザーがプロパティ
IsActiveMicrosoft Entra ID で true に設定されていることを示します。 - アプリケーションに割り当てられる と、ユーザーが Microsoft Entra ID でアプリケーションに割り当てられていることを示します。
- スコープ同期の全体は、スコープ設定によりテナント内のすべてのユーザーとグループが許可されていることを示しています。
- ユーザーが必要なロールを持っている場合は 、ユーザーがアプリケーションにプロビジョニングするために必要なロールを持っていることを示します。
- スコープ フィルター は、アプリケーションのスコープ フィルターを定義している場合にも表示されます。 フィルターは、{スコープ フィルターのタイトル} {スコープ フィルターの属性} {スコープ フィルターの演算子} {スコープ フィルターの値} の形式で表示されます。
トラブルシューティングのヒント
- 有効なスコープ ロールを定義済みであることを確認します。 たとえば、 Greater_Than演算子 を整数以外の値で使用しないでください。
- ユーザーに必要なロールがない場合は、 既定のアクセス ロールに割り当てられているユーザーをプロビジョニングするためのヒントを確認します。
手順 4:ソースとターゲット間でユーザーを照合する
この手順では、インポート手順で取得されたユーザーと、ターゲット システム内のユーザーの照合が、サービスによって試みられます。
詳細を表示する
[ 詳細の表示] ページには、ターゲット システムで一致したユーザーのプロパティが表示されます。 コンテキスト ウィンドウは次のように変更されます。
- ターゲット システム内で一致したユーザーがいなければ、プロパティは表示されません。
- ターゲット システム内で一致したユーザーが 1 人の場合は、そのユーザーのプロパティが表示されます。
- 複数のユーザーが一致する場合は、両方のユーザーのプロパティが表示されます。
- 複数の一致する属性が属性マッピングに含まれる場合、一致する属性それぞれが順次評価されて、その属性について一致したユーザーが表示されます。
トラブルシューティングのヒント
- プロビジョニング サービスで、ソース システム内のユーザーとターゲット内のユーザーを、一意に一致させることができない場合があります。 この問題は、一致する属性が一意のものであるようにすることで解決できます。
- 一致する属性として定義されている属性に基づくフィルター処理が、ターゲット システムでサポートされていることを確認してください。
手順 5:アクションを実行する
最後に、プロビジョニング サービスにより、ユーザーの作成、更新、削除、スキップなどのアクションが実行されます。
次に、ユーザーのオンデマンド プロビジョニングが成功した後に表示される内容の例を示します。
詳細を表示する
[ 詳細の表示] セクションには、ターゲット システムで変更された属性が表示されます。 この表示は、プロビジョニング サービスのアクティビティの最終出力と、エクスポートされた属性を表しています。 この手順が失敗した場合、表示された属性は、プロビジョニング サービスが変更を試みた属性を表します。
トラブルシューティングのヒント
- 変更のエクスポートの失敗は、大きく異なる可能性があります。 一般的 なエラーについては、プロビジョニング ログのドキュメント を参照してください。
- オンデマンド プロビジョニングでは、グループまたはユーザーはアプリケーションに割り当てられないため、プロビジョニングできません。 オブジェクトがアプリケーションに割り当てられてから、その割り当てがオンデマンド プロビジョニングによって受け入れられるまでには、最大数分のレプリケーション遅延があります。 数分待ってからやり直す必要がある場合があります。
よく寄せられる質問
オンデマンド プロビジョニングを使用するには、プロビジョニングをオフにする必要がありますか? 認可のために、有効期間の長いベアラー トークンまたはユーザー名とパスワードを使用するアプリケーションでは、追加の手順は必要ありません。 承認のために OAuth を使用するアプリケーションでは、現在のところ、オンデマンド プロビジョニングを使用する前にプロビジョニング ジョブを停止する必要があります。 G Suite、Box、Workplace by Facebook、Slack などのアプリケーションは、このカテゴリに分類されます。 プロビジョニング ジョブを停止する必要なく、すべてのアプリケーションでオンデマンド プロビジョニングをサポートするための作業が進行中です。
オンデマンド プロビジョニングには、どのくらいの時間がかかりますか? オンデマンド プロビジョニングの所要時間は、通常 30 秒未満です。
既知の制限事項
現時点では、オンデマンド プロビジョニングにはいくつかの既知の制限事項があります。 次に行う改善点をより適切に判断できるように、 ご提案やフィードバック を投稿してください。
注
以下の制限事項は、オンデマンド プロビジョニング機能に固有のものです。 アプリケーションがプロビジョニングのグループ、削除、またはその他の機能をサポートしているかどうかについては、そのアプリケーションのチュートリアルを確認してください。
- グループのオンデマンド プロビジョニングでは、一度に最大 5 人のメンバーの更新がサポートされます。 テナント間同期や Workday などのコネクタでは、グループのプロビジョニングはサポートされていないため、グループのオンデマンド プロビジョニングはサポートされません。
- オンデマンド プロビジョニング要求 API では、一度に最大 5 人のメンバーを持つ 1 つのグループのみを受け入れることができます。
- テナント間同期では、グループのオンデマンド プロビジョニングはサポートされていません。
- オンデマンド プロビジョニングでは、Microsoft Entra 管理センターを使用して一度に 1 人のユーザーをプロビジョニングできます。
- ターゲット テナント内でオンデマンド プロビジョニングを使用して以前に論理的に削除されたユーザーの復元は、サポートされません。 オンデマンド プロビジョニングを使用してユーザーを論理的に削除した後、そのユーザーを復元しようとすると、ユーザーの重複が発生するおそれがあります。
- ロールのオンデマンド プロビジョニングはサポートされていません。
- オンデマンド プロビジョニングでは、アプリケーションから割り当て解除されたユーザーの無効化をサポートしています。 しかし、Microsoft Entra ID から無効化または削除されたユーザーの無効化や削除はサポートされていません。 これらのユーザーは、ユーザーを検索するときに表示されません。
- オンデマンド プロビジョニングでは、アプリケーションに直接割り当てられない入れ子になったグループはサポートされていません。