Microsoft Entra ID での自動ユーザー プロビジョニングのデプロイを計画する
多くの組織は、エンドユーザーの生産性に関して、ServiceNow、Zscaler、Slack などのサービスとしてのソフトウェア (SaaS) アプリケーションに依存しています。 従来、IT スタッフは、各 SaaS アプリケーションのユーザー ID を安全に管理するために、CSV ファイルをアップロードしたりカスタム スクリプトを使用したりするなどの手動のプロビジョニング方法に依存してきました。 これらのプロセスは、エラーが発生しやすく、安全でなく、管理が困難です。
Microsoft Entra の自動ユーザー プロビジョニングは、ビジネス ルールに基づいて SaaS アプリケーションでのユーザー ID の作成、保守、削除を安全に自動化することにより、このプロセスを簡素化します。 この自動化により、クラウドベースのソリューションへの依存を拡大するときに、クラウド専用環境とハイブリッド環境の両方で ID 管理システムを効果的に拡大することができます。
この機能の詳細については、Microsoft Entra ID による SaaS アプリへのユーザー プロビジョニングとプロビジョニング解除の自動化に関するページを参照してください。
Microsoft Entra の自動ユーザー プロビジョニングでは、SaaS アプリケーションへのプロビジョニングに加え、多くのオンプレミスおよびプライベート クラウド アプリケーションへのプロビジョニングもサポートしています。 詳細については、「Microsoft Entra オンプレミス アプリケーション ID プロビジョニングのアーキテクチャ」を参照してください。
学習する
ユーザー プロビジョニングによって、継続的な ID ガバナンスの基盤が作成され、信頼性の高い ID データに依存するビジネス プロセスの品質が向上します。
主な利点
自動ユーザー プロビジョニングを有効にすると、主に次のような利点があります。
生産性の向上。 1 つのユーザー プロビジョニング管理インターフェイスで、複数の SaaS アプリケーションにわたってユーザー ID を管理できます。 このインターフェイスには、プロビジョニング ポリシーの単一のセットがあります。
リスクの管理。 ロールやアクセス権を定義する従業員の状態またはグループ メンバーシップに基づいて変更を自動化することで、セキュリティを強化できます。
コンプライアンスとガバナンスへの対応。 Microsoft Entra ID では、すべてのユーザー プロビジョニング要求のネイティブ監査ログがサポートされます。 要求は、ソース システムとターゲット システムの両方で実行されます。 監査ログを使用すると、1 つの画面から、どのユーザーがアプリケーションにアクセスできるかを追跡できます。
コスト削減。 自動ユーザー プロビジョニングを使用すると、手動プロビジョニングに関連した非効率性や人的エラーを回避することでコストが削減されます。 これにより、独自開発のユーザー プロビジョニング ソリューション、スクリプト、および監査ログの必要性が軽減されます。
ライセンス
Microsoft Entra ID では、アプリケーション ギャラリー メニューに用意されているテンプレートを使用して、任意のアプリケーションのセルフサービス統合を提供します。 ライセンス要件の完全なリストについては、「Microsoft Entra の価格のページを参照してください。
アプリケーションのライセンス
自動的にプロビジョニングするアプリケーションの適切なライセンスが必要になります。 アプリケーションに割り当てられたユーザーがアプリケーション ロールに適したライセンスを持っているかどうかを、アプリケーション所有者と話し合ってください。 Microsoft Entra ID でロールに基づいて自動プロビジョニングを管理する場合、Microsoft Entra ID で割り当てられるロールをアプリケーション ライセンスと一致させる必要があります。 アプリケーションで所有されているライセンスが正しくないと、ユーザーのプロビジョニングまたは更新中にエラーが発生する可能性があります。
用語
この記事では、次の用語を使用しています。
CRUD 操作 - ユーザー アカウントに対して実行されるアクション: 作成、読み取り、更新、削除。
シングル サインオン (SSO) - ユーザーが一度のサインオンですべての SSO 対応アプリケーションにアクセスできるようにする機能。 ユーザー プロビジョニングのコンテキストにおいて、SSO は、自動ユーザー プロビジョニングを使用するすべてのシステムにアクセスするための単一アカウントをユーザーが持つことの結果です。
ソース システム - Microsoft Entra ID のプロビジョニング元であるユーザーのリポジトリ。 Microsoft Entra ID は、事前統合されているほとんどのプロビジョニング コネクタのソース システムです。 ただし、SAP、Workday、AWS などのクラウド アプリケーションにはいくつかの例外があります。 例として、Workday から AD へのユーザー プロビジョニングに関する記事を参照してください。
ターゲット システム - Microsoft Entra ID のプロビジョニング先であるユーザーのリポジトリ。 ターゲット システムは、通常、ServiceNow、Zscaler、Slack などの SaaS アプリケーションです。 ターゲット システムは、AD などのオンプレミス システムにすることもできます。
System for Cross-domain Identity Management (SCIM) - ユーザー プロビジョニングの自動化を可能にするオープン スタンダード。 SCIM は、ID プロバイダーとサービス プロバイダーとの間で、ユーザー ID データをやりとりします。 Microsoft は、ID プロバイダーの一例です。 Salesforce は、サービス プロバイダーの一例です。 サービス プロバイダーはユーザー ID 情報を必要とし、ID プロバイダーはその必要を満たします。 SCIM は、ID プロバイダーとサービス プロバイダーが情報を送受信するために使用するメカニズムです。
トレーニング リソース
| リソース | リンクと説明 |
|---|---|
| オンデマンド ウェビナー | Microsoft Entra ID を使用してエンタープライズ アプリケーションを管理する Microsoft Entra ID を利用してエンタープライズ SaaS アプリケーションへの SSO を実現する方法と、アクセスを制御するためのベスト プラクティスについて説明します。 |
| ビデオ | Azure Active Directory でのユーザー プロビジョニングとは Azure Active Directory でユーザー プロビジョニングをデプロイする方法 Salesforce と Microsoft Entra ID の統合: ユーザー プロビジョニングを自動化する方法 |
| オンライン コース | SkillUp オンライン: ID の管理 Microsoft Entra ID と多くの SaaS アプリケーションを統合する方法と、それらのアプリケーションへのユーザー アクセスをセキュリティで保護する方法について説明します。 |
| 書籍 | Web アプリケーション向けの Microsoft Entra ID による最新の認証 (開発者リファレンス) 初版。 これは、これらの新しい環境向けに Active Directory 認証ソリューションを構築するための、信頼性の高い詳細なガイドです。 |
| チュートリアル | SaaS アプリと Microsoft Entra ID を統合する方法に関するチュートリアルの一覧を参照してください。 |
| よく寄せられる質問 | 自動化されたユーザー プロビジョニングに関してよく寄せられる質問 |
ソリューションのアーキテクチャ
Microsoft Entra プロビジョニング サービスでは、各アプリケーション ベンダーから提供されるユーザー管理 API エンドポイントに接続して、SaaS アプリや他のシステムにユーザーをプロビジョニングします。 これらのユーザー管理 API エンドポイントを使用すると、Microsoft Entra ID ではプログラムによってユーザーを作成、更新、削除できます。
ハイブリッド エンタープライズ向けの自動ユーザー プロビジョニング
この例では、ユーザーとグループは、オンプレミスのディレクトリに接続されている HR データベースに作成されます。 Microsoft Entra プロビジョニング サービスでは、ターゲット SaaS アプリケーションへの自動ユーザー プロビジョニングを管理します。
ワークフローの説明:
ユーザー/グループは、オンプレミスの HR アプリケーション/システム (SAP など) で作成されます。
Microsoft Entra Connect エージェントが、スケジュールされたローカル AD から Microsoft Entra ID への ID (ユーザーおよびグループ) の同期を実行します。
Microsoft Entra プロビジョニング サービスが、ソース システムとターゲット システムに対して初回サイクルを実行します。
Microsoft Entra プロビジョニング サービスが、初回サイクル以降に変更されたすべてのユーザーおよびグループについて、ソース システムに対してクエリを実行し、変更を増分サイクルにプッシュします。
クラウド専用エンタープライズの自動ユーザー プロビジョニング
この例では、ユーザーの作成は Microsoft Entra ID で行われ、Microsoft Entra プロビジョニング サービスでは、ターゲット (SaaS) アプリケーションへの自動ユーザー プロビジョニングを管理します。
ワークフローの説明:
Microsoft Entra ID でユーザーおよびグループが作成されます。
Microsoft Entra プロビジョニング サービスが、ソース システムとターゲット システムに対して初回サイクルを実行します。
Microsoft Entra プロビジョニング サービスが、初回サイクル以降に更新されたすべてのユーザーとグループについて、ソース システムに対してクエリを実行し、増分サイクルを実行します。
クラウド HR アプリケーションの自動ユーザー プロビジョニング
この例では、ユーザーとグループは、Workday や SuccessFactors などのクラウド人事アプリケーションで作成されます。 Microsoft Entra プロビジョニング サービスと Microsoft Entra Connect プロビジョニング エージェントは、クラウド人事アプリのテナントから AD にユーザー データをプロビジョニングします。 AD でアカウントが更新されると、Microsoft Entra Connect を介して Microsoft Entra ID と同期され、電子メール アドレスとユーザー名の属性をクラウド人事アプリのテナントに書き戻すことができます。
- 人事チームは、クラウド人事アプリのテナントでトランザクションを実行します。
- Microsoft Entra プロビジョニング サービスが、スケジュールされたサイクルをクラウド人事アプリのテナントから実行し、AD との同期のために処理する必要がある変更を識別します。
- Microsoft Entra プロビジョニング サービスが、AD アカウントの作成、更新、有効化、無効化の操作を含む要求ペイロードを使用して、Microsoft Entra Connect プロビジョニング エージェントを呼び出します。
- Microsoft Entra Connect プロビジョニング エージェントが、サービス アカウントを使用して AD アカウントのデータを管理します。
- Microsoft Entra Connect が、デルタ同期を実行して AD 内の更新をプルします。
- AD の更新が、Microsoft Entra ID と同期されます。
- Microsoft Entra プロビジョニング サービスが、Microsoft Entra ID からクラウド人事アプリのテナントにメール属性とユーザー名を書き戻します。
デプロイ プロジェクトを計画する
組織のニーズを考慮して、環境にユーザー プロビジョニングをデプロイするための戦略を決定します。
適切な関係者を関わらせる
テクノロジ プロジェクトが失敗した場合、その原因は通常、影響、結果、および責任に対する想定の不一致です。 これらの落とし穴を回避するには、適切な利害関係者を関与させ、利害関係者およびそのプロジェクトの情報と説明責任を文書化することで、プロジェクトでの利害関係者の役割をよく理解させます。
連絡を計画する
コミュニケーションは、新しいサービスの成功に必要不可欠です。 ユーザーのエクスペリエンスについて、どのようにエクスペリエンスが変わるか、いつ変わる予定か、また問題が発生した場合にどのようにサポートを受けられるかについてユーザーに事前に伝えます。
パイロットを計画する
自動ユーザー プロビジョニングの初期構成は、運用環境のすべてのユーザーに拡張する前に、小規模なユーザー サブセットを含むテスト環境で行うことをお薦めします。 パイロットの実行については、ベストプラクティスに関する記事を参照してください。
パイロットのベスト プラクティス
パイロットを使用することにより、すべてのユーザーに対して機能をデプロイする前に、小規模なグループでテストすることができます。 テストの一部として、組織内の各ユース ケースが十分にテストされていることを確認します。
最初の段階では、テストを受けてフィードバックを提供できる IT、ユーザビリティ、およびその他の適切なユーザーを対象にします。 このフィードバックを使用して、ユーザーに伝える情報と指示をさらに発展させ、サポート スタッフが直面する可能性がある問題の種類に関する分析情報を提供します。
対象となるグループの範囲を広げて、ロールアウトをより大きなユーザー グループに拡大します。 グループのスコープの拡大は、動的グループ メンバーシップを使用するか、対象グループにユーザーを手動で追加することで実行できます。
アプリケーションの接続と管理を計画する
Microsoft Entra 管理センターを使用して、プロビジョニングをサポートするすべてのアプリケーションを表示および管理します。 「ポータルでアプリを検索する」を参照してください。
使用するコネクタの種類を決定する
自動プロビジョニングを有効にし、構成するために実際に必要な手順は、アプリケーションによって異なります。 自動的にプロビジョニングしたいアプリケーションが Microsoft Entra SaaS アプリ ギャラリーに一覧表示されている場合は、アプリ固有の統合チュートリアルを選択して、事前統合されたユーザー プロビジョニング コネクタを構成します。
そうでない場合は、次の手順に従ってください。
事前統合されたユーザー プロビジョニング コネクタの要求を作成します。 SCIM がサポートされている場合にお客様のアプリケーションを Microsoft のプラットフォームにオンボードするために、Microsoft のチームはお客様およびアプリケーション開発者と連携します。
アプリに対する BYOA SCIM 汎用ユーザー プロビジョニング サポートを使用します。 Microsoft Entra ID では、事前統合されたプロビジョニング コネクタを使用せずにユーザーをアプリにプロビジョニングするには、SCIM の使用が必須です。
アプリケーションが BYOA SCIM コネクタを利用できる場合は、BYOA SCIM 統合チュートリアルを参照して、アプリケーションに対して BYOA SCIM コネクタを構成します。
詳細については、「Microsoft Entra の自動ユーザー プロビジョニングで利用できるアプリケーションとシステム」を参照してください。
アプリケーションへのアクセスを承認するための情報を収集する
自動ユーザー プロビジョニングの設定は、アプリケーションごとのプロセスです。 ターゲット システムのユーザー管理エンドポイントに接続するには、アプリケーションごとに管理者の資格情報を指定する必要があります。
この画像は、必要な管理者資格情報の 1 つのバージョンを示しています。
![ユーザー アカウントでのプロビジョニング設定を管理する [プロビジョニング] 画面](media/plan-auto-user-provisioning/userprovisioning-admincredentials.png)
アプリケーションの中には、管理者のユーザー名とパスワードが必要なものもあれば、ベアラー トークンが必要なものもあります。
ユーザーとグループのプロビジョニングを計画する
エンタープライズ アプリに対してユーザー プロビジョニングを有効にすると、Microsoft Entra 管理センター で、属性マッピングを通じてその属性値が制御されます。
各 SaaS アプリの操作を決定する
各アプリケーションには、Microsoft Entra ID 内の属性にマップする必要がある一意のユーザーまたはグループの属性が含まれている場合があります。 アプリケーションは、使用可能な CRUD 操作のサブセットのみを持つことができます。
アプリケーションごとに、次の情報を文書化します。
ターゲット システムのユーザー オブジェクトとグループ オブジェクトに対して実行される CRUD プロビジョニング操作。 たとえば、各 SaaS アプリのビジネス所有者は、可能なすべての操作を必要としない場合があります。
ソース システムで使用可能な属性
ターゲット システムで使用可能な属性
システム間での属性のマッピング。
プロビジョニングするユーザーとグループを選択する
自動ユーザー プロビジョニングを実装する前に、アプリケーションにプロビジョニングするユーザーとグループを決定する必要があります。
スコープ フィルターを使用して、アプリケーションにプロビジョニングするユーザーを決める、属性ベースのルールを定義します。
次に、さらにフィルター処理するために、必要に応じてユーザーとグループの割り当てを使用します。
ユーザーとグループの属性マッピングを定義する
自動ユーザー プロビジョニングを実装するには、アプリケーションに必要なユーザーとグループの属性を定義する必要があります。 Microsoft Entra ユーザー オブジェクトと各 SaaS アプリケーションのユーザー オブジェクトの間には、事前構成済みの一連の属性と属性マッピングが存在します。 すべての SaaS アプリでグループ属性が有効化されるわけではありません。
Microsoft Entra ID では、属性から属性への直接マッピング、定数値の提供、または属性マッピングの式の作成によってサポートされます。 この柔軟性により、ターゲット システムの属性に設定される内容を細かく制御できます。 Microsoft Graph API と Graph Explorer を使用して、ユーザー プロビジョニングの属性マッピングとスキーマを JSON ファイルにエクスポートし、それを Microsoft Entra ID にインポートして戻すことができます。
詳細については、「Microsoft Entra ID で SaaS アプリケーションのユーザー プロビジョニング属性マッピングをカスタマイズする」を参照してください。
ユーザー プロビジョニングに関する特別な考慮事項
デプロイ後の問題を減らすために、次の点を考慮してください。
ソース アプリケーションとターゲット アプリケーションの間でユーザー/グループ オブジェクトをマップするために使用される属性が回復性を備えていることを確認します。 属性が変更されても (ユーザーが社内の別の場所に移動した場合など)、ユーザーやグループが誤ってプロビジョニングされないようにする必要があります。
アプリケーションには、ユーザー プロビジョニングが正しく機能するために満たす必要がある特定の制限や要件がある場合があります。 たとえば、Slack では、特定の属性の値が切り捨てられます。 各アプリケーションに固有の自動ユーザー プロビジョニング チュートリアルを参照してください。
ソース システムとターゲット システム間のスキーマの整合性を確認します。 よくある問題としては、一致しない UPN やメールなどの属性があります。 たとえば、UPN は、Microsoft Entra ID では john_smith@contoso.com と設定され、アプリでは jsmith@contoso.com になります。 詳細については、ユーザーとグループのスキーマ リファレンスに関する記事を参照してください。
テストとセキュリティを計画する
デプロイの各段階で、必ず、結果が予想どおりであることをテストし、プロビジョニング サイクルを監査するようにします。
テストを計画する
まず、アプリケーションのために自動ユーザー プロビジョニングを構成します。 次に、テスト ケースを実行して、ソリューションが組織の要件を満たしているかどうか確認します。
| シナリオ | 予想される結果 |
|---|---|
| ターゲット システムに割り当てられているグループにユーザーが追加される。 | ユーザー オブジェクトがターゲット システムでプロビジョニングされている。 ユーザーがターゲット システムにサインインして、目的のアクションを実行できる。 |
| ターゲット システムに割り当てられているグループからユーザーが削除される。 | ユーザー オブジェクトがターゲット システムでプロビジョニング解除される。 ユーザーがターゲットシステムにサインインできない。 |
| Microsoft Entra ID で、ユーザー情報が任意の方法で更新される。 | 増分サイクル後、更新されたユーザー属性がターゲット システムで反映される。 |
| ユーザーがスコープ外である。 | ユーザー オブジェクトが無効化または削除される。 注:Workday のプロビジョニングでは、この動作はオーバーライドされます。 |
セキュリティを計画する
通常、デプロイの一環としてセキュリティ レビューが必要になります。 セキュリティ レビューが必要な場合は、サービスとしての ID の概要を示す Microsoft Entra ID のホワイトペーパーが多数用意されているので、それらを参照してください。
ロールバックを計画する
自動ユーザー プロビジョニングの実装が運用環境で期待どおりに機能しない場合は、以下のロールバック手順が、前の既知の正常な状態に戻すのに役立ちます。
プロビジョニング ログを確認して、影響を受けたユーザーやグループに対して行われた誤った操作を判別します。
プロビジョニング監査ログを使用して、影響を受けたユーザーまたはグループについて最新の既知の正常な状態を判別します。 また、ソース システム (Microsoft Entra ID または AD) も確認します。
アプリケーションの所有者と協力し、最新の既知の正常な状態の値を使用して、アプリケーションで直接影響を受けたユーザーやグループを更新します。
自動ユーザー プロビジョニング サービスをデプロイする
ソリューションの要件に合わせて手順を選択します。
初回サイクルの準備をする
Microsoft Entra プロビジョニング サービスを初めて実行すると、ソース システムとターゲット システムに対して実行される初回サイクルで、各ターゲット システムのすべてのユーザー オブジェクトのスナップショットが作成されます。
アプリケーションに対して自動プロビジョニングを有効にする場合、初回サイクルには 20 分から数時間かかります。 この時間は、Microsoft Entra ディレクトリのサイズと、プロビジョニングの対象となるユーザーの数によって異なります。
プロビジョニング サービスは、初回サイクル後の両方のシステムの状態を保管し、後続の増分サイクルのパフォーマンスを改善します。
自動ユーザー プロビジョニングの構成
Microsoft Entra 管理センター を使用して、サポートされているアプリケーションのための自動ユーザー アカウント プロビジョニングとプロビジョニング解除を管理します。 アプリケーションへの自動プロビジョニングの設定方法に関する記事の手順に従ってください。
Microsoft Entra ユーザー プロビジョニング サービスは、Microsoft Graph API を使用して構成および管理することもできます。
自動ユーザー プロビジョニングを管理する
これでデプロイが完了したので、ソリューションを管理する必要があります。
ユーザー プロビジョニング操作の正常性を監視する
初回サイクルが正常に完了すると、Microsoft Entra プロビジョニング サービスは、次のいずれかのイベントが発生するまで、各アプリケーションに固有の間隔で無制限に増分更新を実行します。
サービスが手動で停止され、Microsoft Entra 管理センター を使用するか、適切な Microsoft Graph API コマンドを使用して、新しい初回サイクルがトリガーされる。
新しい初回サイクルによって、属性マッピングまたはスコープ フィルターの変更がトリガーされる。
エラー率が高いためにプロビジョニング プロセスが検疫に移行し、4 週間より長く検疫にとどまり、自動的に無効になる。
これらのイベントと、プロビジョニング サービスによって実行されるその他のすべてのアクティビティを確認するには、Microsoft Entra のプロビジョニング ログを参照してください。
プロビジョニング サイクルの所要時間を把握し、プロビジョニング ジョブの進行状況を監視するために、ユーザー プロビジョニングの状態を確認することができます。
レポートから分析情報を得る
Microsoft Entra ID は、監査ログとレポートを介して、組織のユーザー プロビジョニングの使用状況と運用の正常性について追加の分析情報を提供します。 ユーザーの分析情報の詳細については、「ユーザー プロビジョニングの状態を確認する」を参照してください。
管理者は、プロビジョニングの概要レポートを確認して、プロビジョニング ジョブの操作の正常性を監視する必要があります。 プロビジョニング サービスによって実行されたアクティビティはすべて、Microsoft Entra の監査ログに記録されます。 「チュートリアル:自動ユーザー アカウント プロビジョニングについてのレポート」を参照してください。
これらのレポートの所有権を引き受け、組織の要件が満たされる頻度で使用することをお勧めします。 Microsoft Entra ID では、ほとんどの監査データが 30 日間保持されます。
トラブルシューティング
プロビジョニング中に発生する可能性がある問題のトラブルシューティングについては、次のリンクを参照してください。
アプリケーションにプロビジョニングするためにオンプレミスの Active Directory から Microsoft Entra ID に属性を同期する
Microsoft Entra ギャラリー アプリケーションへのユーザー プロビジョニングを構成している間の管理者の資格情報の保存に関する問題