数秒でユーザーまたはグループをプロビジョニングするには、オンデマンド プロビジョニングを使用します。 この機能を使用すると、特に以下のことが可能です。
- 構成の問題を迅速にトラブルシューティングする。
- 定義した式を検証する。
- スコープ フィルターをテストする。
オンデマンド プロビジョニングの使用方法
ヒント
この記事の手順は、開始するポータルによって若干異なる場合があります。
- アプリケーション管理者以上の権限で Microsoft Entra 管理センターにサインインします。
- [ID]>[アプリケーション]>[エンタープライズ アプリケーション]> を参照し、アプリケーションを選択します。
- [プロビジョニング] を選択します。
- [ID]>[External Identities]>[テナント間同期]>[構成] の順に参照します
- 目的の構成を選択してから、プロビジョニング構成ページに移動します。
管理者の資格情報を指定してプロビジョニングを構成します。
[Provision on demand] (オンデマンドでプロビジョニングする) を選択します。
名、姓、表示名、ユーザー プリンシパル名、またはメール アドレスでユーザーを検索します。 または、グループを検索し、最大 5 人のユーザーを選択することもできます。
Note
クラウド人事プロビジョニング アプリ (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 つまたは複数が表示される可能性があります。
- [ソース システムでアクティブ] は、Microsoft Entra ID で、そのユーザーの
IsActiveプロパティが true に設定されていることを示します。 - [アプリケーションに割り当て済み] は、Microsoft Entra ID で、そのユーザーがアプリケーションに割り当てられていることを示します。
- [Scope sync all](すべてをスコープ同期) : スコープ設定で、テナント内のすべてのユーザーおよびグループが許可されることを示します。
- [User has required role](ユーザーは必要なロールを所有) : ユーザーが、アプリケーションにプロビジョニングするために必要なロールを持っていることを示します。
- [スコープ フィルター] : アプリケーション用のスコープ フィルターを定義済みの場合は、これも表示されます。 フィルターは、{スコープ フィルターのタイトル} {スコープ フィルターの属性} {スコープ フィルターの演算子} {スコープ フィルターの値} の形式で表示されます。
トラブルシューティングのヒント
- 有効なスコープ ロールを定義済みであることを確認します。 たとえば、整数以外の値と共に 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 から無効化または削除されたユーザーの無効化や削除はサポートされていません。 これらのユーザーは、ユーザーを検索するときに表示されません。
- オンデマンド プロビジョニングでは、アプリケーションに直接割り当てられない入れ子になったグループはサポートされていません。