Azure Active Directory でのオンデマンド プロビジョニング

数秒でユーザーをアプリケーションにプロビジョニングするには、オンデマンド プロビジョニングを使用します。 この機能を使用すると、特に以下のことが可能です。

  • 構成の問題を迅速にトラブルシューティングする。
  • 定義した式を検証する。
  • スコープ フィルターをテストする。

オンデマンド プロビジョニングの使用方法

  1. Azure portal にサインインします。

  2. [すべてのサービス] > [エンタープライズ アプリケーション] と移動します。

  3. 目的のアプリケーションを選択してから、プロビジョニング構成ページに移動します。

  4. 管理者の資格情報を指定してプロビジョニングを構成します。

  5. [Provision on demand] (オンデマンドでプロビジョニングする) を選択します。

  6. 名、姓、表示名、ユーザー プリンシパル名、またはメール アドレスでユーザーを検索します。

    注意

    クラウド HR プロビジョニング アプリ (Workday、SuccessFactors から AD、Azure AD) の場合、入力値は異なります。 Workday のシナリオの場合は、Workday でのユーザーの "WID" を指定してください。 SuccessFactors のシナリオの場合は、SuccessFactors でのユーザーの "personIdExternal" を指定してください。

  7. ページの下部にある [プロビジョニング] を選択します。

ユーザーをオンデマンドでプロビジョニングするための Azure portal UI を示すスクリーンショット。

プロビジョニングの手順について

ユーザーをプロビジョニングするときには、オンデマンド プロビジョニング プロセスによって、プロビジョニング サービスで実行される手順の表示が試みられます。 ユーザーをプロビジョニングする手順は、通常は 5 つあります。 オンデマンド プロビジョニング エクスペリエンスの間には、以降のセクションで説明する手順のうち、1 つ以上が表示されます。

手順 1:接続テスト

プロビジョニング サービスにより、"テスト ユーザー" に対する要求が作成され、ターゲット アプリケーションへのアクセスの承認が試みられます。 プロビジョニング サービスでは、サービスがプロビジョニング手順の続行を承認したことを示す応答が想定されています。 このステップは、失敗時にのみ表示されます。 手順が成功した場合は、オンデマンド プロビジョニング エクスペリエンスの間に表示されません。

トラブルシューティングのヒント

  • ターゲット アプリケーションに対して、シークレット トークンやテナント URL などの有効な資格情報を指定したことを確認します。 必要な資格情報はアプリケーションによって異なります。 構成に関する詳細なチュートリアルについては、チュートリアルの一覧を参照してください。
  • [属性マッピング] ペインで定義されている、一致する属性に基づくフィルター処理が、ターゲット アプリケーションでサポートされていることを確認します。 サポートされているフィルターを知るために、アプリケーション開発者によって提供される API ドキュメントを調べる必要が生じることがあります。
  • クロスドメイン ID 管理システム (SCIM) アプリケーションの場合は、Postman などのツールを使用できます。 このようなツールを利用すると、承認要求に対して、Azure Active Directory (Azure AD) プロビジョニング サービスが予期している方法で確実にアプリケーションを応答させることができます。 要求の例を参照してください。

手順 2:ユーザーをインポートする

次に、プロビジョニング サービスにより、ソース システムからユーザーが取得されます。 サービスが取得するユーザー属性は、以下のために後で使用されます。

  • ユーザーがプロビジョニングのスコープ内にあるかどうかを評価します。
  • 既存のユーザーがいないかターゲット システムを調べます。
  • ターゲット システムにどのユーザー属性をエクスポートするかを決定します。

詳細を表示する

[詳細の表示] セクションには、ソース システム (Azure AD など) からインポートされたユーザーのプロパティが表示されます。

トラブルシューティングのヒント

  • ソース システム内のユーザー オブジェクトに一致する属性がない場合、ユーザーのインポートは失敗する可能性があります。 このエラーを解決するには、以下のいずれかの方法を試してください。

    • 一致している属性の値を使用して、ユーザー オブジェクトを更新します。
    • プロビジョニングの構成で、一致する属性を変更します。
  • インポートされた一覧に、予期した属性がない場合は、ソース システムのユーザー オブジェクトで、属性に値があることを確認します。 プロビジョニング サービスでは、現在、null 属性のプロビジョニングはサポートされていません。

  • プロビジョニング構成の [属性マッピング] ページに、予期している属性が含まれていることを確認します。

手順 3:ユーザーがスコープ内にあるかどうかを確認する

次に、プロビジョニング サービスにより、ユーザーがプロビジョニングのスコープ内にあるかどうかが確認されます。 サービスによって考慮されるのは以下のような側面です。

  • ユーザーがアプリケーションに割り当てられているかどうか。
  • スコープは、割り当てられた同期 に設定されているか、すべて同期 に設定されているか。
  • プロビジョニング構成で定義されているスコープ フィルター。

詳細を表示する

[詳細の表示] セクションには、評価されたスコープ条件が表示されます。 以下のプロパティのうち、1 つまたは複数が表示される可能性があります。

  • [Active in source system] (ソース システムでアクティブ) : Azure AD で、そのユーザーの IsActive プロパティが true に設定されていることを示します。
  • [アプリケーションに割り当て済み] : Azure AD で、そのユーザーがアプリケーションに割り当てられていることを示します。
  • [Scope sync all](すべてをスコープ同期) : スコープ設定で、テナント内のすべてのユーザーおよびグループが許可されることを示します。
  • [User has required role](ユーザーは必要なロールを所有) : ユーザーが、アプリケーションにプロビジョニングするために必要なロールを持っていることを示します。
  • [スコープ フィルター] : アプリケーション用のスコープ フィルターを定義済みの場合は、これも表示されます。 フィルターは、{スコープ フィルターのタイトル} {スコープ フィルターの属性} {スコープ フィルターの演算子} {スコープ フィルターの値} の形式で表示されます。

トラブルシューティングのヒント

手順 4:ソースとターゲット間でユーザーを照合する

この手順では、インポート手順で取得されたユーザーと、ターゲット システム内のユーザーの照合が、サービスによって試みられます。

詳細を表示する

[詳細の表示] ページには、ターゲット システム内で一致したユーザーのプロパティが表示されます。 コンテキスト ウィンドウに表示されるプロパティは、以下のようにさまざまです。

  • ターゲット システム内で一致したユーザーがいなければ、どのプロパティも表示されません。
  • ターゲット システム内で一致したユーザーが 1 人の場合は、その一致したユーザーの、ターゲット システムでのプロパティが表示されます。
  • 複数のユーザーが一致した場合、一致したユーザー両方のプロパティが表示されます。
  • 複数の一致する属性が属性マッピングに含まれる場合、一致する属性それぞれが順次評価されて、その属性について一致したユーザーが表示されます。

トラブルシューティングのヒント

  • プロビジョニング サービスで、ソース システム内のユーザーとターゲット内のユーザーを、一意に一致させることができない場合があります。 この問題は、一致する属性が一意のものであるようにすることで解決できます。
  • 一致する属性として定義されている属性に基づくフィルター処理が、ターゲット アプリケーションでサポートされていることを確認してください。

手順 5:アクションを実行する

最後に、プロビジョニング サービスにより、ユーザーの作成、更新、削除、スキップなどのアクションが実行されます。

次に、ユーザーのオンデマンド プロビジョニングが成功した後に表示される内容の例を示します。

ユーザーのオンデマンド プロビジョニングが成功したことを示すスクリーンショット。

詳細を表示する

[詳細の表示] セクションには、ターゲット アプリケーションで変更された属性が表示されます。 この表示は、プロビジョニング サービスのアクティビティの最終出力と、エクスポートされた属性を表しています。 この手順が失敗した場合、表示された属性は、プロビジョニング サービスが変更を試みた属性を表します。

トラブルシューティングのヒント

よく寄せられる質問

  • オンデマンド プロビジョニングを使用するには、プロビジョニングをオフにする必要がありますか? 承認のために、有効期間の長いベアラー トークンまたはユーザー名とパスワードを使用するアプリケーションでは、追加の手順は必要ありません。 承認のために OAuth を使用するアプリケーションでは、現在のところ、オンデマンド プロビジョニングを使用する前にプロビジョニング ジョブを停止する必要があります。 G Suite、Box、Workplace by Facebook、Slack などのアプリケーションは、このカテゴリに分類されます。 プロビジョニング ジョブを停止する必要なく、すべてのアプリケーションでオンデマンド プロビジョニングをサポートするための作業が進行中です。

  • オンデマンド プロビジョニングには、どのくらいの時間がかかりますか? オンデマンド プロビジョニングの所要時間は、通常 30 秒未満です。

既知の制限事項

現時点では、オンデマンド プロビジョニングにはいくつかの既知の制限事項があります。 提案とフィードバックを投稿していただけると、次に改善する点をより的確に判断できます。

注意

以下の制限事項は、オンデマンド プロビジョニング機能に固有のものです。 アプリケーションがプロビジョニングのグループ、削除、またはその他の機能をサポートしているかどうかについては、そのアプリケーションのチュートリアルを確認してください。

  • アマゾン ウェブ サービス (AWS) アプリケーションの場合、オンデマンド プロビジョニングはサポートされていません。
  • グループとロールのオンデマンド プロビジョニングはサポートされていません。
  • オンデマンド プロビジョニングでは、アプリケーションから割り当て解除されたユーザーの無効化をサポートしています。 ただし、Azure AD から無効化または削除されたユーザーの無効化または削除はサポートしていません。 これらのユーザーは、ユーザーを検索するときに表示されません。

次のステップ