Azure Active Directory でのアプリケーションのプロビジョニングのしくみ

自動プロビジョニングとは、ユーザーがアクセスする必要のあるクラウド アプリケーションのユーザー ID とロールを作成することです。 自動プロビジョニングには、ユーザー ID の作成に加えて、状態または役割が変化したときのユーザー ID のメンテナンスおよび削除が含まれます。 デプロイを開始する前に、この記事を参照して Azure AD プロビジョニングのしくみを学習し、構成に関する推奨事項を確認することができます。

Azure AD プロビジョニング サービス では、アプリケーション ベンダーから提供される System for Cross-Domain Identity Management (SCIM) 2.0 ユーザー管理 API エンドポイントに接続することによって、SaaS アプリや他のシステムにユーザーがプロビジョニングされます。 Azure AD では、この SCIM エンドポイントを使用して、プログラムによってユーザーが作成、更新、削除されます。 また、一部の限られたアプリケーションについては、ID に関連したその他のオブジェクト (グループ、ロールなど) をプロビジョニング サービスで作成、更新、削除することができます。 Azure AD とアプリケーションの間のプロビジョニングに使用されるチャネルは、HTTPS TLS 1.2 暗号化を使用して暗号化されます。

Azure AD プロビジョニング サービス 図 1: Azure AD プロビジョニング サービス

出力方向のユーザー プロビジョニング ワークフロー 図 2: Azure AD から主要 SaaS アプリケーションへの "出力方向" のユーザー プロビジョニング ワークフロー

入力方向のユーザー プロビジョニング ワークフロー 図 3: 主要な人材管理 (HCM) アプリケーションから Azure Active Directory および Windows Server Active Directory への "入力方向" のユーザー プロビジョニング ワークフロー

SCIM 2.0 を使用したプロビジョニング

Azure AD プロビジョニング サービスでは、自動プロビジョニングに SCIM 2.0 プロトコルが使用されます。 このサービスは、アプリケーションの SCIM エンドポイントに接続され、SCIM ユーザー オブジェクト スキーマおよび REST API を使用してユーザーとグループのプロビジョニングとプロビジョニング解除が自動化されます。 Azure AD ギャラリーでは、ほとんどのアプリケーションに対して SCIM ベースのプロビジョニング コネクタが用意されています。 Azure AD 用のアプリをビルドする場合、開発者は SCIM 2.0 ユーザー管理 API を使用して、プロビジョニングのために Azure AD を統合する SCIM エンドポイントを構築できます。 詳細については、SCIM エンドポイントの構築とプロビジョニングの構成に関するページを参照してください。

自動 Azure AD プロビジョニング コネクタが現在ないアプリに対してこのコネクタを要求するには、Azure Active Directory アプリケーション要求に入力します。

承認

Azure AD をアプリケーションのユーザー管理 API に接続するには、資格情報が必要です。 アプリケーションの自動ユーザー プロビジョニングを構成している間に、有効な資格情報を入力する必要があります。 ギャラリー アプリケーションの場合、アプリケーションの資格情報の種類と要件については、アプリのチュートリアルを参照してください。 ギャラリー以外のアプリケーションの場合は、SCIM のドキュメントを参照して、資格情報の種類と要件を理解することができます。 Azure portal で、資格情報をテストできます (Azure AD により、指定された資格情報を使用してアプリのプロビジョニング アプリへの接続が試行されます)。

属性のマッピング

サード パーティの SaaS アプリケーションでユーザー プロビジョニングを有効にすると、Azure portal では属性マッピングによってその属性値が管理されます。 マッピングにより、ユーザー アカウントをプロビジョニングまたは更新するときに Azure AD とターゲット アプリケーションの間でフローするユーザー属性が決定されます。

Azure AD ユーザー オブジェクトと各 SaaS アプリのユーザー オブジェクトの間には、構成済みの一連の属性と属性マッピングが存在します。 アプリによっては、ユーザーに加えてグループなど他の種類のオブジェクトを管理するものもあります。

プロビジョニングを設定するときは、どのユーザー (またはグループ) プロパティが Azure AD からアプリケーションに提供されるかを定義する属性マッピングとワークフローを確認して構成することが重要です。 2 つのシステム間でユーザーまたはグループを一意に識別して照合するために使用される照合プロパティ (この属性を使用してオブジェクトを照合します) を確認して構成します。

既定の属性マッピングをビジネスのニーズに合わせてカスタマイズできます。 そのため、既存の属性マッピングを変更、削除したり、新規の属性マッピングを作成したりすることができます。 詳細については、SaaS アプリケーションに対するユーザー プロビジョニング属性マッピングのカスタマイズに関するページを参照してください。

SaaS アプリケーションに対してプロビジョニングを構成するときに指定できる属性マッピングの種類の 1 つは、式マッピングです。 これらのマッピングでは、ユーザーのデータを SaaS アプリケーションが許容可能な形式に変換することができる、スクリプトのような式を記述する必要があります。 詳細については、属性マッピングの式の書き方に関するページを参照してください。

Scoping

割り当てベースのスコープ

Azure AD から SaaS アプリケーションへの送信プロビジョニングでは、ユーザーまたはグループの割り当てに依存することが、プロビジョニングの対象となるユーザーを特定する最も一般的な方法です。 ユーザー割り当てはシングル サインオンの有効化にも使用されるため、アクセスとプロビジョニングの両方を管理するのに同じ方法を使用できます。 割り当てベースのスコープは、Workday や Successfactors などの受信プロビジョニング シナリオには適用されません。

  • [グループ]。 Azure AD Premium ライセンス プランを利用すると、グループを使用して SaaS アプリケーションにアクセスを割り当てることができます。 プロビジョニング スコープが、割り当てられているユーザーおよびグループのみを同期する ように設定されている場合、Azure AD プロビジョニング サービスでは、アプリケーションに割り当てられているグループのメンバーであるかどうかに基づいてユーザーがプロビジョニングまたはプロビジョニング解除されます。 アプリケーションでグループ オブジェクトがサポートされていない場合、グループ オブジェクト自体はプロビジョニングされません。 アプリケーションに割り当てられているグループで、プロパティ "SecurityEnabled" が "True" に設定されていることを確認します。

  • 動的グループ。 Azure AD ユーザー プロビジョニング サービスでは、動的グループのユーザーの読み取りとプロビジョニングを行うことができます。 次の注意事項と推奨事項に留意してください。

    • 動的グループは、Azure AD から SaaS アプリケーションへのエンドツーエンドのプロビジョニングのパフォーマンスに影響を与えることがあります。

    • SaaS アプリケーションで動的グループのユーザーをプロビジョニングまたはプロビジョニング解除する速度は、動的グループでメンバーシップの変更を評価する速さによって決まります。 動的グループの処理状態を確認する方法については、メンバーシップ ルールの処理状態のチェックに関するページを参照してください。

    • 動的グループのユーザーのメンバーシップが失われると、プロビジョニング解除イベントと見なされます。 動的グループのルールを作成する場合は、このシナリオを検討してください。

  • 入れ子になったグループ。 Azure AD ユーザー プロビジョニング サービスでは、入れ子になったグループのユーザーの読み取りやプロビジョニングを行うことはできません。 このサービスでは、明示的に割り当てられたグループの直接のメンバーであるユーザーだけを読み取ってプロビジョニングすることができます。 "アプリケーションへのグループベースの割り当て" のこの制限は、シングル サインオンにも影響を与えます (「SaaS アプリケーションへのアクセスをグループで管理する」を参照)。 代わりに、プロビジョニングする必要のあるユーザーを含むグループを明示的に割り当てるか、またはスコープ設定します。

属性ベースのスコープ

スコープ フィルターを使用して、アプリケーションにプロビジョニングするユーザーを決める、属性ベースのルールを定義できます。 この方法は、一般的に、HCM アプリケーションから Azure AD および Active Directory への受信プロビジョニングに使用されます。 スコープ フィルターは各 Azure AD ユーザー プロビジョニング コネクタの属性マッピングで設定されます。 属性ベースのスコープ フィルターの構成の詳細については、「スコープ フィルターを使用した属性ベースのアプリケーション プロビジョニング」を参照してください。

B2B (ゲスト) ユーザー

Azure AD ユーザー プロビジョニング サービスを使って、Azure AD の B2B (またはゲスト) ユーザーを SaaS アプリケーションにプロビジョニングすることは可能です。 ただし、B2B ユーザーが、Azure AD を使用して SaaS アプリケーションにサインインするには、SaaS アプリケーションで、SAML ベースのシングル サインオン機能が特定の方法で構成されている必要があります。 B2B ユーザーからのサインインをサポートするように SaaS アプリケーションを構成する方法の詳細については、「B2B コラボレーション用の SaaS アプリの構成」を参照してください。

注意

ゲスト ユーザーの userPrincipalName は、多くの場合、"alias#EXT#@domain.com" として表示されます。 userPrincipalName がソース属性として属性マッピングに含まれている場合、#EXT# は userPrincipalName から削除されます。 #EXT# が存在する必要がある場合は、ソース属性としての userPrincipalName を originalUserPrincipalName に置き換えてください。

userPrincipalName = alias@domain.com originalUserPrincipalName = alias#EXT#@domain.com

プロビジョニング サイクル:初回と増分

Azure AD がソース システムである場合、プロビジョニング サービスは「デルタ クエリを使用して、Microsoft Graph データの変更を追跡する」を使用してユーザーとグループを監視します。 プロビジョニング サービスは、ソース システムとターゲット システムに対して初回サイクルを実行した後、増分サイクルを定期的に行います。

初回サイクル

プロビジョニング サービスが開始されたときの初回サイクルでは、次の処理が実行されます。

  1. ソース システムのすべてのユーザーとグループにクエリを実行し、属性マッピングで定義されているすべての属性を取得します。

  2. 返されたユーザーおよびグループを、構成済み割り当てまたは属性ベースのスコープ フィルターを使用してフィルター処理します。

  3. ユーザーが割り当て済み、またはプロビジョニング対象の場合、サービスはターゲット システムに対してクエリを実行し、指定された照合属性を使用して、一致するユーザーがいないかどうかを確認します。 例:ソース システムの userPrincipal 名が一致属性であり、ターゲット システムの userName にマップされる場合、プロビジョニング サービスは、ターゲット システムにクエリを実行し、ソース システムの userPrincipal 名の値と一致する userName がないかどうかを確認します。

  4. 一致するユーザーがターゲット システムで見つからない場合、ソース システムから返された属性を使用してユーザーが作成されます。 ユーザー アカウントが作成されると、プロビジョニング サービスでは、その新しいユーザー用のターゲット システムの ID が検出されてキャッシュされます。 この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。

  5. 一致するユーザーが見つかった場合、そのユーザーは、ソース システムによって提供された属性を使用して更新されます。 ユーザー アカウントが照合されると、プロビジョニング サービスでは、その新しいユーザー用のターゲット システムの ID が検出されてキャッシュされます。 この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。

  6. 属性マッピングに "参照" 属性が含まれている場合、サービスは、ターゲット システムで追加の更新を実行して参照先オブジェクトを作成し、リンクします。 たとえば、あるユーザーがターゲット システムで "Manager" 属性を持ち、それがターゲット システムで作成された別のユーザーにリンクされている場合があります。

  7. 初回サイクルの終了時に基準値を保持します。これは、以降の増分サイクルの始点になります。

ServiceNow、G Suite、Box など、アプリケーションの中には、ユーザーのプロビジョニングだけでなく、グループとそのメンバーのプロビジョニングをサポートしているものがあります。 このような場合、グループのプロビジョニングがマッピングで有効になっていると、プロビジョニング サービスは、ユーザーとグループを同期したうえで、グループ メンバーシップを同期します。

増分サイクル

初回サイクルの後、他のすべてのサイクルでは以下が行われます。

  1. ソース システムにクエリを実行し、前回の基準値が保存された後に更新されたユーザーおよびグループがないかどうかを確認します。

  2. 返されたユーザーおよびグループを、構成済み割り当てまたは属性ベースのスコープ フィルターを使用してフィルター処理します。

  3. ユーザーが割り当て済み、またはプロビジョニング対象の場合、サービスはターゲット システムに対してクエリを実行し、指定された照合属性を使用して、一致するユーザーがいないかどうかを確認します。

  4. 一致するユーザーがターゲット システムで見つからない場合、ソース システムから返された属性を使用してユーザーが作成されます。 ユーザー アカウントが作成されると、プロビジョニング サービスでは、その新しいユーザー用のターゲット システムの ID が検出されてキャッシュされます。 この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。

  5. 一致するユーザーが見つかった場合、そのユーザーは、ソース システムによって提供された属性を使用して更新されます。 照合されたのが新しく割り当てられたアカウントである場合、プロビジョニング サービスでは、その新しいユーザー用のターゲット システムの ID が検出されてキャッシュされます。 この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。

  6. 属性マッピングに "参照" 属性が含まれている場合、サービスは、ターゲット システムで追加の更新を実行して参照先オブジェクトを作成し、リンクします。 たとえば、あるユーザーがターゲット システムで "Manager" 属性を持ち、それがターゲット システムで作成された別のユーザーにリンクされている場合があります。

  7. 以前プロビジョニングの対象であったユーザーが対象から外れた場合 (割り当てられていない場合を含む)、このサービスでは、更新を通じてターゲット システムでこのユーザーが無効化されます。

  8. 以前プロビジョニングの対象だったユーザーが、ソース システムで無効にされた場合、または論理削除された場合、サービスは、更新によってターゲット システムのユーザーを無効にします。

  9. 以前プロビジョニングの対象だったユーザーが、ソース システムから物理的に削除された場合、サービスは、ターゲット システムのユーザーを削除します。 Azure AD では、論理削除されたユーザーは、削除されてから 30 日後に物理的に削除されます。

  10. 増分サイクルの終了時に新しい基準値を保持します。これは、以降の増分サイクルの始点になります。

注意

[マッピング] セクションの [対象オブジェクトのアクション] チェック ボックスを使用して、 [作成][更新] 、または [削除] 操作を必要に応じて無効にできます。 更新中にユーザーを無効にするロジックは、"accountEnabled" などのフィールドの属性マッピングでも制御されます。

プロビジョニング サービスでは、バックツーバック増分サイクルが、各アプリケーションに固有のチュートリアルで定義された間隔で無期限に実行され続けます。 増分サイクルは、次のいずれかのイベントが発生するまで続行されます。

  • Azure portal または適切な Microsoft Graph API コマンドを使用してサービスが手動で停止された。
  • Azure portal の [プロビジョニングを再起動] オプション、または適切な Microsoft Graph API コマンドを使用して、新しい初回サイクルがトリガーされます。 この操作では、保存された基準値がクリアされ、すべてのソース オブジェクトが再評価されます。
  • 属性マッピングまたはスコープ フィルターの変更によって、新しい初回サイクルがトリガーされた。 また、この操作では、保存された基準値がクリアされ、すべてのソース オブジェクトが再評価されます。
  • 高いエラー率によりプロビジョニング プロセスが検疫に移行し (以下を参照)、そのまま 4 週間を超えて検疫にとどまっている。 この場合、サービスは自動的に無効になります。

エラーと再試行

ターゲット システムでのエラーが原因で個々のユーザーの追加、更新、または削除がターゲットシステム上で行えない場合、その操作は次の同期サイクルで再試行されます。 エラーは継続的に再試行され、再試行頻度は徐々に減らされます。 エラーを解決するには、管理者がプロビジョニング ログを確認し、根本原因を特定して、適切な対応を取る必要があります。 たとえば、次のような一般的なエラーがあります。

  • ターゲット システムで必要な属性がソース システムのユーザーに設定されていない
  • ソース システムのユーザーの属性値に対して、ターゲット システムに一意の制約があり、同じ値が他のユーザー レコードに存在する

このようなエラーを解決するには、ソース システムで影響を受けるユーザーの属性値を調整するか、競合が発生しないように属性マッピングを調整します。

検疫

ターゲット システムに対する呼び出しのほとんどまたはすべてが、常にエラー (管理者の資格情報が無効である場合など) が原因で失敗する場合、プロビジョニング ジョブは "検疫" 状態になります。 この状態は、プロビジョニング概要レポート、または電子メール (電子メール通知が Azure portal で構成されている場合) で示されます。

検疫状態であると、増分サイクルの頻度は徐々に減少し、最終的には 1 日 1 回になります。

問題を引き起こしているすべてのエラーが修正されたら、プロビジョニング ジョブは検疫から削除され、次の同期サイクルが開始されます。 プロビジョニング ジョブが検疫にとどまっている期間が 4 週間を超えると、そのプロビジョニング ジョブは無効になります。 検疫の状態の詳細については、こちらを参照してください。

プロビジョニングにかかる時間

プロビジョニング ジョブで実行されているのが初期プロビジョニング サイクルか増分サイクルかによって、パフォーマンスが異なります。 プロビジョニングにかかる時間、およびプロビジョニング サービスの状態を監視する方法について詳しくは、ユーザー プロビジョニングの状態の確認に関するページをご覧ください。

ユーザーが正しくプロビジョニングされているかどうかを確認する方法

ユーザー プロビジョニング サービスによって実行された操作はすべて、Azure AD のプロビジョニング ログ (プレビュー) に記録されます。 このログには、ソース システムとターゲット システムに対して実行されたすべての読み取りおよび書き込み操作と、各操作の際に読み取られたり書き込まれたりしたユーザー データが含まれます。 Azure portal でプロビジョニング ログを確認する方法については、プロビジョニング レポートに関するガイドを参照してください。

プロビジョニング解除

Azure AD プロビジョニング サービスを使用すると、ユーザー アクセスが削除された場合に、アカウントをプロビジョニング解除することによってソースおよびターゲット システムの同期が維持されます。

ユーザーの削除と無効化 (論理的な削除とも呼ばれます) の両方が、このプロビジョニング サービスによってサポートされています。 無効化と削除の厳密な定義は、ターゲット アプリの実装によって異なりますが、一般に、無効化とはユーザーがサインインできないことを示します。 削除とは、ユーザーがアプリケーションから完全に削除されたことを示します。 SCIM アプリケーションの場合、無効化は、ユーザーに対して active プロパティを false に設定する要求です。

ユーザーを無効にするようにアプリケーションを構成する

更新プログラムのチェックボックスを確実にオンにしておきます。

ご利用のアプリケーション用の active のマッピングを確保します。 アプリケーション ギャラリーからのアプリケーションを使用している場合は、マッピングが若干異なることがあります。 ギャラリー アプリケーションの場合は、既定の、またはすぐに利用できるマッピングを確実に使用してください。

ユーザーを無効にします

ユーザーを削除するようにアプリケーションを構成する

次のシナリオでは、無効化または削除がトリガーされます。

  • Azure AD 内でユーザーを論理的に削除する (ごみ箱に入れられます、AccountEnabled プロパティが false に設定されます)。 Azure AD でユーザーが削除されてから 30 日後に、テナントから完全に削除されます。 この時点で、プロビジョニング サービスによって削除要求が送信されて、アプリケーション内のユーザーが完全に削除されます。 30 日間の期間中はいつでも、ユーザーを手動で完全に削除することができます。これにより、削除要求がアプリケーションに送信されます。
  • ユーザーを Azure AD のごみ箱から完全に削除または除去する。
  • ユーザーをアプリから割り当て解除する。
  • ユーザーをスコープ内からスコープ外に移動する (スコープ フィルターを通過しなくなります)。

ユーザーの削除

既定では、Azure AD プロビジョニング サービスにより、スコープ外になったユーザーが論理的に削除または無効化されます。 この既定の動作をオーバーライドする場合は、スコープ外の削除をスキップするようにフラグを設定します。

上記の 4 つのイベントのいずれかが発生し、ターゲット アプリケーションで論理的な削除がサポートされていない場合は、プロビジョニング サービスによって削除要求が送信されて、アプリからユーザーが完全に削除されます。

属性マッピングに IsSoftDeleted 属性が表示されている場合は、この属性を使用してユーザーの状態とともに、active = false の更新要求を送信してユーザーを論理的に削除するかどうかが判断されます。

既知の制限事項

  • 以前にプロビジョニング サービスによって管理されていたユーザーがアプリから、またはアプリに割り当てられたグループから、割り当てが解除される場合は、無効化要求を送信します。 その時点で、ユーザーはこのサービスによって管理されていないので、彼らがディレクトリから削除されるとき、削除要求は送信しません。
  • Azure AD 内で無効になっているユーザーのプロビジョニングはサポートされていません。 プロビジョニングするには、事前に Azure AD 内でアクティブになっている必要があります。
  • ユーザーが論理的に削除された状態からアクティブになると、Azure AD プロビジョニング サービスによってそのユーザーはターゲット アプリ内でアクティブにされますが、グループ メンバーシップは自動的には復元されません。 ターゲット アプリケーションによって、ユーザーのグループ メンバーシップは非アクティブ状態で維持されます。 ターゲット アプリケーションでこれがサポートされていない場合は、プロビジョニングを再開してグループ メンバーシップを更新することができます。

推奨

アプリケーションを開発する場合は、論理的な削除と物理的な削除の両方を常にサポートしてください。 そうすることで、顧客は、ユーザーが誤って無効にされた場合でも回復することができます。

次の手順

自動ユーザー プロビジョニングのデプロイを計画する

ギャラリー アプリのプロビジョニングを構成する

独自のアプリを作成するときに SCIM エンドポイントを構築してプロビジョニングを構成する

アプリケーションに対するユーザーの構成およびプロビジョニングに関する問題のトラブルシューティング