多くの組織は、エンドユーザーの生産性に関して、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 などのオンプレミス システムにすることもできます。
クロスドメイン ID 管理 (SCIM) のシステム - ユーザー プロビジョニングの自動化を可能にするオープン標準。 SCIM は、ID プロバイダーとサービス プロバイダーとの間で、ユーザー ID データをやりとりします。 Microsoft は、ID プロバイダーの一例です。 Salesforce は、サービス プロバイダーの一例です。 サービス プロバイダーはユーザー ID 情報を必要とし、ID プロバイダーはその必要を満たします。 SCIM は、ID プロバイダーとサービス プロバイダーが情報を送受信するために使用するメカニズムです。
トレーニング リソース
| リソース | リンクと説明 |
|---|---|
| オンデマンド ウェビナー | Microsoft Entra ID を使用してエンタープライズ アプリケーションを管理する Microsoft Entra ID を利用してエンタープライズ SaaS アプリケーションへの SSO を実現する方法と、アクセスを制御するためのベスト プラクティスについて学習します。 |
| ビデオ | Active Azure Directory でのユーザー プロビジョニングとは Active Azure Directory にユーザー プロビジョニングをデプロイする方法 Salesforce と Microsoft Entra ID の統合: ユーザー プロビジョニングを自動化する方法 |
| オンライン コース | SkillUp Online: ID の管理 Microsoft Entra ID を多くの SaaS アプリケーションと統合し、それらのアプリケーションへのユーザー アクセスをセキュリティで保護する方法について学習します。 |
| 書籍 | Web アプリケーション用の Microsoft Entra ID を使用した先進認証 (開発者向けリファレンス) 第 1 版。 これは、これらの新しい環境向けに 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 プロビジョニング サービス は、クラウド HR アプリ テナントからスケジュールされたサイクルを実行し、AD との同期のために処理する必要がある変更を識別します。
- Microsoft Entra プロビジョニング サービス は、AD アカウントの作成/更新/有効化/無効化操作を含む要求ペイロードを使用して、Microsoft Entra Connect プロビジョニング エージェントを呼び出します。
- Microsoft Entra Connect プロビジョニング エージェント は、サービス アカウントを使用して AD アカウント データを管理します。
- Microsoft Entra Connect は差分同期を実行して、AD で更新プログラムをプルします。
- AD 更新プログラムは Microsoft Entra ID と同期されます。
- Microsoft Entra プロビジョニング サービス は、Microsoft Entra ID からクラウド HR アプリ テナントに電子メール属性とユーザー名を書き戻します。
デプロイ プロジェクトを計画する
組織のニーズを考慮して、環境にユーザー プロビジョニングをデプロイするための戦略を決定します。
適切な関係者を関わらせる
テクノロジ プロジェクトが失敗した場合、その原因は通常、影響、結果、および責任に対する想定の不一致です。 このような落とし穴を回避するには、 適切な利害関係者を関与 させ、利害関係者とそのプロジェクトの入力と説明責任を文書化することで、プロジェクトの利害関係者の役割が十分に理解されていることを確認します。
連絡を計画する
コミュニケーションは、新しいサービスの成功に必要不可欠です。 ユーザーのエクスペリエンスについて、どのようにエクスペリエンスが変わるか、いつ変わる予定か、また問題が発生した場合にどのようにサポートを受けられるかについてユーザーに事前に伝えます。
パイロットを計画する
自動ユーザー プロビジョニングの初期構成は、運用環境のすべてのユーザーに拡張する前に、小規模なユーザー サブセットを含むテスト環境で行うことをお薦めします。 パイロットの実行については、ベストプラクティスに関する記事を参照してください。
パイロットのベスト プラクティス
パイロットを使用することにより、すべてのユーザーに対して機能をデプロイする前に、小規模なグループでテストすることができます。 テストの一部として、組織内の各ユース ケースが十分にテストされていることを確認します。
最初の段階では、テストを受けてフィードバックを提供できる IT、ユーザビリティ、およびその他の適切なユーザーを対象にします。 このフィードバックを使用して、ユーザーに伝える情報と指示をさらに発展させ、サポート スタッフが直面する可能性がある問題の種類に関する分析情報を提供します。
対象となるグループの範囲を広げて、ロールアウトをより大きなユーザー グループに拡大します。 グループのスコープを増やすには、 動的メンバーシップ グループ を使用するか、ターゲット グループにユーザーを手動で追加します。
アプリケーションの接続と管理を計画する
Microsoft Entra 管理センターを使用して、プロビジョニングをサポートするすべてのアプリケーションを表示および管理します。 ポータルでのアプリの検索を参照してください。
使用するコネクタの種類を決定する
自動プロビジョニングを有効にし、構成するために実際に必要な手順は、アプリケーションによって異なります。 自動的にプロビジョニングするアプリケーションが Microsoft Entra SaaS アプリ ギャラリーに一覧表示されている場合は、 アプリ固有の統合チュートリアル を選択して、事前に設定されたユーザー プロビジョニング コネクタを構成する必要があります。
そうでない場合は、次の手順に従ってください。
事前に設定されたユーザー プロビジョニング コネクタの要求を作成します。 SCIM がサポートされている場合にお客様のアプリケーションを Microsoft のプラットフォームにオンボードするために、Microsoft のチームはお客様およびアプリケーション開発者と連携します。
アプリの BYOA SCIM 汎用ユーザー プロビジョニング サポートを使用します。 事前統合されたプロビジョニング コネクタなしでアプリにユーザーをプロビジョニングするには、SCIM の使用が Microsoft Entra ID で必須です。
アプリケーションが BYOA SCIM コネクタを利用できる場合は、 BYOA SCIM 統合チュートリアル を参照して、アプリケーションの BYOA SCIM コネクタを構成します。
詳細については、「Microsoft Entra の自動ユーザー プロビジョニングで使用できるアプリケーションとシステム」を参照してください。
アプリケーションへのアクセスを承認するための情報を収集する
自動ユーザー プロビジョニングの設定は、アプリケーションごとのプロセスです。 アプリケーションごとに、ターゲット システムのユーザー管理エンドポイントに接続するための 管理者資格情報 を指定する必要があります。
この画像は、必要な管理者資格情報の 1 つのバージョンを示しています。
アプリケーションの中には、管理者のユーザー名とパスワードが必要なものもあれば、ベアラー トークンが必要なものもあります。
ユーザーとグループのプロビジョニングを計画する
エンタープライズ アプリのユーザー プロビジョニングを有効にした場合、 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 アプリケーションのユーザー プロビジョニング Attribute-Mappings のカスタマイズ」を参照してください。
ユーザー プロビジョニングに関する特別な考慮事項
デプロイ後の問題を減らすために、次の点を考慮してください。
ソース アプリケーションとターゲット アプリケーションの間でユーザー/グループ オブジェクトをマップするために使用される属性が回復性を備えていることを確認します。 属性が変更されても (ユーザーが社内の別の場所に移動した場合など)、ユーザーやグループが誤ってプロビジョニングされないようにする必要があります。
アプリケーションには、ユーザー プロビジョニングが正しく機能するために満たす必要がある特定の制限や要件がある場合があります。 たとえば、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 Gallery アプリケーションへのユーザー プロビジョニングの構成中に管理者の資格情報を保存する際の問題
Microsoft Entra Gallery アプリケーションにプロビジョニングされているユーザーのセットが間違っている