Microsoft Entra のユーザー プロビジョニングに対するクラウド人事アプリケーション

従来、IT スタッフは、手動による社員の作成、更新、削除の方法に依存していました。 これらは、CSV ファイルのアップロードや、カスタム スクリプトなどの方法を使用して社員データを同期しています。 これらのプロビジョニング プロセスは、エラーが発生しやすく、安全でなく、管理が困難です。

従業員、ベンダー、または臨時従業員の ID ライフサイクルを管理するために、 Microsoft Entra ユーザー プロビジョニング サービス は、クラウドベースの人事 (HR) アプリケーションとの統合を提供します。 アプリケーションの例には、Workday や SuccessFactors などがあります。

Microsoft Entra ID は、この統合を利用して、次のクラウド人事アプリケーション (アプリ) プロセスを有効にします。

• Active Directory へのユーザーのプロビジョニング: クラウド人事アプリから選択したユーザー セットを 1 つ以上の Active Directory ドメインにプロビジョニングします。
• クラウド専用ユーザーを Microsoft Entra ID にプロビジョニングします。 Active Directory を使用しないシナリオでは、クラウド人事アプリから Microsoft Entra ID にユーザーを直接プロビジョニングします。
• クラウド人事アプリに書き戻します。 Microsoft Entra のメール アドレスとユーザー名属性をクラウド人事アプリに書き戻します。

次のビデオでは、人事主導のプロビジョニング統合の計画に関するガイダンスを提供します。

任意の HR システムからの API 駆動型プロビジョニング

API 駆動型プロビジョニングでは、任意のレコード システムの ID を Microsoft Entra ID に取り込むことができます。 "任意" の自動化ツール使用をして、レコードのシステムから従業員データを取得し、Microsoft Entra ID に取り込むことができます。 IT 管理者は、属性マッピングを使用してデータを処理および変換する方法を完全に制御できます。

有効な人事シナリオ

Microsoft Entra ユーザー プロビジョニング サービスを使用すると、次に示す人事ベースの ID ライフサイクル管理シナリオを自動化できます。

• 新入社員雇用: クラウド人事アプリに従業員を追加すると、Active Directory と Microsoft Entra ID にユーザーが自動的に作成されます。 ユーザー アカウントの追加には、メール アドレスとユーザー名の属性をクラウド人事アプリに書き戻すオプションが含まれています。
• 従業員属性とプロファイルの更新: クラウド人事アプリで名前、タイトル、マネージャーなどの従業員レコードが更新されると、Active Directory と Microsoft Entra ID でユーザー アカウントが自動的に更新されます。
• 従業員の退職: 従業員がクラウド人事アプリで退職すると、Active Directory と Microsoft Entra ID でユーザー アカウントが自動的に無効になります。
• 従業員の再雇用: 従業員がクラウド人事アプリで再雇用されると、古いアカウントを自動的に再アクティブ化したり、Active Directory と Microsoft Entra ID に再プロビジョニングしたりできます。

この統合が最も適している組織

クラウド人事アプリの Microsoft Entra ユーザー プロビジョニングとの統合は、次のような組織に最適です。

• クラウド人事のユーザーをプロビジョニングするための、事前構築済みのクラウドベースのソリューションを必要としている。
• クラウド人事アプリから Active Directory または Microsoft Entra ID に直接、ユーザーをプロビジョニングする必要がある。
• クラウド人事アプリから取得したデータを使用してユーザーをプロビジョニングする必要がある。
• 入社、異動、退職するユーザーの同期。 同期は、クラウド人事アプリで検出された変更情報のみに基づいて、1 つ以上の Active Directory フォレスト、ドメイン、OU の間で行われる。
• 電子メールに Microsoft 365 を使用する。

学習する

ユーザー プロビジョニングによって、継続的な ID ガバナンスの基盤が作成されます。 これにより、正規の ID データに依存するビジネス プロセスの品質が向上します。

用語

この記事では、次の用語を使用しています。

• ソース システム: Microsoft Entra ID がプロビジョニングするユーザーのリポジトリ。 例として、Workday や SuccessFactors などのクラウド人事アプリがあります。
• ターゲット システム: Microsoft Entra ID がプロビジョニングするユーザーのリポジトリ。 例として、Active Directory、Microsoft Entra ID、Microsoft 365、その他の SaaS アプリがあります。
• 参加者 -Movers-Leavers プロセス: クラウド人事アプリをレコードのシステムとして使用して、新入社員、異動、退職に使用される用語。 プロセスが完了するのは、サービスによって必要な属性がターゲット システムに正常にプロビジョニングされた時点です。

主な利点

ここで説明する人事ベースの IT プロビジョニング機能は、次に挙げるような大きなメリットをビジネスにもたらします。

• 生産性の向上: ユーザー アカウントと Microsoft 365 ライセンスの割り当てを自動化し、キー グループへのアクセスを提供できるようになりました。 割り当ての自動化により、新しい社員は各自の業務ツールにすぐにアクセスできるため、生産性が向上します。
• リスクの管理: 従業員の状態またはグループ メンバーシップに基づいて変更を自動化し、セキュリティを強化します。 この自動化により、ユーザー ID とキー アプリへのアクセスが自動的に更新されます。 たとえば、ユーザーが異動したり退職したりしたときに、人事アプリの更新が自動的に流れます。
• コンプライアンスとガバナンスに対処する: Microsoft Entra ID は、ソース システムとターゲット システムの両方のアプリによって実行されるユーザー プロビジョニング要求のネイティブ プロビジョニング ログをサポートします。 監査によって、誰がアプリにアクセスできるかを 1 つの画面から追跡できます。
• コストの管理: 自動プロビジョニングでは、手動プロビジョニングに関連する非効率性と人的エラーを回避することで、コストが削減されます。 従来の陳腐化したプラットフォームを使用して、長らく構築されてきた、カスタム開発のユーザー プロビジョニング ソリューションを不要にします。

ライセンス

Microsoft Entra ユーザー プロビジョニング統合にクラウド HR アプリを構成するには、有効な Microsoft Entra ID P1 または P2 ライセンス と、Workday や SuccessFactors などのクラウド HR アプリのライセンスが必要です。

クラウド人事アプリから入手し、Active Directory または Microsoft Entra ID にプロビジョニングされるすべてのユーザーについても、Microsoft Entra ID P1 以上の有効なサブスクリプション ライセンスが必要です。

プロビジョニング プロセスで ライフサイクル ワークフロー やその他の Microsoft Entra ID ガバナンス機能を使用するには、 Microsoft Entra ID ガバナンス ライセンスが必要です。

前提条件

• Connect プロビジョニング エージェントを構成するためのハイブリッド ID 管理者ロール。
• プロビジョニング アプリを構成するためのアプリケーション管理者ロール。
• クラウド人事アプリのテストおよび運用インスタンス。
• クラウド人事アプリの管理者権限。システム統合ユーザーを作成したり、テスト目的でテスト用社員データを変更したりするために必要です。
• Active Directory へのユーザー プロビジョニングについては、Microsoft Entra Connect プロビジョニング エージェントをホストするために、Windows Server 2016 以降を実行しているサーバーが必要です。 このサーバーは、Active Directory 管理層モデルに基づいた階層 0 のサーバーである必要があります。
• Active Directory と Microsoft Entra ID の間でユーザーを同期するための Microsoft Entra Connect。

トレーニング リソース

ソリューションのアーキテクチャ

次の例では、一般的なハイブリッド環境に向けた、エンド ツー エンドのユーザー プロビジョニング ソリューションのアーキテクチャについて説明し、次のものが含まれます。

• 正規の人事データ フロー - クラウド人事アプリから Active Directory へ。 このフローでは、クラウド人事アプリのテナントで人事イベント (入社/異動/退職プロセス) が開始されます。 Microsoft Entra プロビジョニング サービスおよび Microsoft Entra Connect プロビジョニング エージェントが、クラウド人事アプリのテナントから Active Directory にユーザー データをプロビジョニングします。 イベントによっては、Active Directory での作成、更新、有効化、および無効化操作が発生する可能性があります。
• Microsoft Entra ID と同期し、オンプレミスの Active Directory からクラウド人事アプリにメール アドレスとユーザー名を書き戻します。 Active Directory でアカウントが更新されると、Microsoft Entra Connect 経由で Microsoft Entra ID と同期されます。 メール アドレスやユーザー名の属性は、クラウド人事アプリ テナントに書き戻すことができます。

プロビジョニング プロセスの説明

次の主要な手順を図に示します。

1. 人事チーム は、クラウド人事アプリ テナントでトランザクションを実行します。
2. Microsoft Entra プロビジョニング サービス は、クラウド HR アプリ テナントからスケジュールされたサイクルを実行し、Active Directory と同期するためのプロセスの変更を識別します。
3. Microsoft Entra プロビジョニング サービス は、Active Directory アカウントの作成、更新、有効化、無効化操作を含む要求ペイロードを使用して、Microsoft Entra Connect プロビジョニング エージェントを呼び出します。
4. Microsoft Entra Connect プロビジョニング エージェント は、サービス アカウントを使用して Active Directory アカウント データを管理します。
5. Microsoft Entra Connect は、差分 同期 を実行して Active Directory で更新プログラムをプルします。
6. Active Directory の 更新プログラムは、Microsoft Entra ID と同期されます。
7. Microsoft Entra プロビジョニング サービス は、Microsoft Entra ID からクラウド HR アプリ テナントに電子メール属性とユーザー名を書き戻します。

デプロイ プロジェクトを計画する

お客様の環境でこのデプロイの戦略を決定するときは、お客様の組織のニーズを考慮してください。

適切な関係者を関わらせる

テクノロジ プロジェクトが失敗した場合、その原因は通常、影響、結果、および責任に対する想定の不一致です。 このような落とし穴を回避するには、 適切な利害関係者に関与していることを確認します。 また、プロジェクトの利害関係者のロールを十分に把握していることを確認します。 利害関係者とそのプロジェクト入力と責務を文書化します。

既存の人事ビジネス プロセスや、社員の ID および職務データの処理要件について意見できる、人事部門の代表者を含めます。

連絡を計画する

コミュニケーションは、新しいサービスの成功に必要不可欠です。 エクスペリエンスの変化について、ユーザーに事前に通知します。 問題が発生した場合にサポートを受ける方法について説明します。

パイロットを計画する

人事ビジネス プロセスと ID ワークフローをクラウド人事アプリからターゲット システムに統合するには、ソリューションを運用環境にデプロイする前に、大量のデータ検証、データ変換、データ クレンジング、そして徹底的なテストが必要です。

運用環境のすべてのユーザーにスケールする前に、 パイロット環境 で初期構成を実行します。

HR データ フローと属性マッピングを計画する

適切な HR レコードが Microsoft Entra ID (Entra ID) とオンプレミスの Active Directory (AD) のユーザーに確実にマップされるように、HR および IT の各チームと協力してデータの一貫性を確保し、データ クレンジング タスクを計画します。 作業を開始するためのベスト プラクティスの一覧を次に示します。

1. 一致する識別子の存在と一意性: プロビジョニング サービスでは、一致する属性を使用して、人事システムのユーザー レコードを一意に識別し、AD/Entra ID の対応するユーザー アカウントとリンクします。 既定の一致する属性は、従業員 ID に基づいています。 完全同期を開始する前に、従業員 ID の値が Entra ID (クラウド専用ユーザーの場合) およびオンプレミスの AD (ハイブリッド ユーザーの場合) に設定されていること、ユーザーを一意に識別することを確認します。 

2. 関連しなくなった HR レコードをスキップするには、スコープ フィルターを使用 します。人事システムには、おそらく1970年代まで遡る数年間の雇用データがあります。 一方、IT チームが関心を持つのは、現在アクティブな従業員の一覧と、稼働後に発生する退職レコードのみである可能性があります。 IT チームの観点から関連性がなくなった HR レコードを除外するには、HR チームと協力して、Microsoft Entra プロビジョニングのスコープ フィルターで使用できる HR レコードにフラグを追加します。 

3. ユーザー名の特殊文字の処理を計画します。 ユーザーの一意の userPrincipalName を作成するには、ワーカーの名と姓を使用するのが一般的です。 userPrincipalName でアクセント記号は使用できません。使用できる文字は A - Z、a - z、0 - 9、 ' . - _ ! # ^ ~. 関数 NormalizeDiacritics を使用してアクセント文字を処理し、適切なuserPrincipalNameを構築します。

4. 長い文字列の処理を計画します。 HR データに、Entra ID/オンプレミス AD 属性の設定に使用する HR フィールドに関連付けられている長い文字列値があるかどうかを確認します。 すべての Entra ID 属性には、最大文字列長があります。 Entra ID 属性にマップされた HR フィールドの値にさらに多くの文字が含まれている場合、属性の更新が失敗する可能性があります。 1 つのオプションは、属性マッピングを確認し、HR システムで長い文字列値を切り捨てたり更新したりする可能性があるかどうかを確認することです。 オプションでない場合は、 Mid などの関数を使用して長い文字列を切り捨てるか、 Switch などの関数を使用して長い値を短い値/省略形にマップすることができます。 

5. 必須属性の null/空の値を処理します。 Entra ID/オンプレミス AD でアカウントを作成するときは、 firstName、 lastName、 CN、 UPN などの特定の属性を設定する必要があります。 そのような属性にマップされた対応する HR フィールドが null の場合、ユーザー作成操作は失敗します。 たとえば、AD の CN 属性を "表示名" にマップした場合、"表示名" がすべてのユーザーに対して設定されていない限り、エラーが発生します。 1 つのオプションは、このような必須の属性マッピングを確認し、対応するフィールドが HR に入力されていることを確認することです。 式マッピングで null 値をチェックするオプションを検討することもできます。 たとえば、表示名が空の場合は、名と姓を連結して表示名を作ります。 

クラウド人事プロビジョニング コネクタ アプリの選択

クラウド人事アプリから Active Directory への Microsoft Entra プロビジョニングを容易にするために、Microsoft Entra アプリ ギャラリーから複数のプロビジョニング コネクタ アプリを追加できます。

• クラウド人事アプリから Active Directory へのユーザー プロビジョニング: このプロビジョニング コネクタ アプリは、クラウド HR アプリから単一の Active Directory ドメインへのユーザー アカウント プロビジョニングを容易にします。 複数のドメインがある場合は、プロビジョニングする必要がある Active Directory ドメインごとに 1 つ、Microsoft Entra アプリ ギャラリーからこのアプリのインスタンスを追加できます。
• クラウド人事アプリから Microsoft Entra へのユーザー プロビジョニング: Microsoft Entra Connect は、オンプレミスの Active Directory ユーザーを Microsoft Entra ID に同期するために使用されるツールです。 クラウド人事アプリから Microsoft Entra へのユーザー プロビジョニングは、クラウドのみのユーザーをクラウド人事アプリから 1 つの Microsoft Entra テナントにプロビジョニングするために使用するコネクタです。
• クラウド人事アプリの書き戻し: このプロビジョニング コネクタ アプリは、Microsoft Entra ID からクラウド HR アプリへのユーザーの電子メール アドレスの書き戻しを容易にします。

たとえば、次の図に、Microsoft Entra アプリ ギャラリーで入手できる Workday コネクタ アプリが一覧表示されています。

意思決定フロー チャート

以下の決定フロー チャートを使用して、お客様のシナリオに関連しているクラウド人事プロビジョニング アプリを特定します。

Microsoft Entra Connect プロビジョニング エージェントのデプロイ トポロジを設計する

クラウド人事アプリと Active Directory 間のプロビジョニング統合には、次の 4 つのコンポーネントが必要です。

• クラウド人事アプリのテナント
• プロビジョニング コネクタ アプリ
• Microsoft Entra Connect プロビジョニング エージェント
• Active Directory ドメイン

Microsoft Entra Connect プロビジョニング エージェントのデプロイ トポロジは、統合を計画しているクラウド人事アプリのテナントおよび Active Directory 子ドメインの数によって異なります。 複数の Active Directory ドメインがある場合は、Active Directory ドメインが連続しているか 不整合であるかによって異なります。

決定に基づいて、次のいずれかのデプロイ シナリオを選択します。

• 1 つのクラウド人事アプリのテナント -> 信頼されたフォレスト内の 1 つまたは複数の Active Directory 子ドメインがターゲット
• 1 つのクラウド人事アプリのテナント -> 分離された Active Directory フォレスト内の複数の子ドメインがターゲット

1 つのクラウド人事アプリのテナント -> 信頼されたフォレスト内の 1 つまたは複数の Active Directory 子ドメインがターゲット

次の運用環境の構成をお勧めします。

1 つのクラウド人事アプリのテナント -> 分離された Active Directory フォレスト内の複数の子ドメインがターゲット

このシナリオでは、クラウド人事アプリから分離された Active Directory フォレスト内のドメインにユーザーをプロビジョニングします。

次の運用環境の構成をお勧めします。

Microsoft Entra Connect プロビジョニング エージェントの要件

クラウド人事アプリから Active Directory へのユーザー プロビジョニング ソリューションは、1 つ以上の Microsoft Entra Connect プロビジョニング エージェントのデプロイを必要とします。 これらのエージェントは、Windows Server 2016 以上を実行するサーバーにデプロイする必要があります。 サーバーは、4 GB 以上の RAM と .NET 4.7.1 以降のランタイムを備えている必要があります。 ホスト サーバーが、ターゲット Active Directory ドメインへのネットワーク アクセスを持っていることを確認します。

オンプレミス環境を準備するために、Microsoft Entra Connect プロビジョニング エージェント構成ウィザードは、エージェントを Microsoft Entra テナントに登録し、 ポートを開き、 URL へのアクセスを許可し、 送信 HTTPS プロキシ構成をサポートします。

プロビジョニング エージェントは、Active Directory ドメインと通信するように グローバル管理サービス アカウント (GMSA) を構成します。

プロビジョニング要求を処理する必要のあるドメイン コント ローラーを選択できます。 地理的に分散されたドメイン コント ローラーが複数ある場合は、優先ドメイン コント ローラーと同じサイトにプロビジョニング エージェントをインストールします。 この配置により、エンド ツー エンドのソリューションの信頼性とパフォーマンスが向上します。

高可用性のために、複数の Microsoft Entra Connect プロビジョニング エージェントをデプロイできます。 エージェントを登録して、同じオンプレミスの Active Directory ドメインのセットを処理します。

HR プロビジョニング アプリのデプロイ トポロジを設計する

受信ユーザー プロビジョニング構成にかかわる Active Directory ドメイン数に応じて、次のいずれかのデプロイ トポロジを検討できます。 各トポロジ図では、デプロイ シナリオの例を使用して、構成の側面を強調しています。 実際のデプロイの要件によく似た例を使用して、ニーズを満たす構成を判断します。

デプロイ トポロジ 1: クラウド人事から 1 つのオンプレミスの Active Directory ドメインにすべてのユーザーをプロビジョニングする単一アプリ

デプロイ トポロジ 1 は、最も一般的なデプロイ トポロジです。 クラウド HR からすべてのユーザーを 1 つの AD ドメインにプロビジョニングする必要があり、すべてのユーザーに同じプロビジョニング ルールが適用される場合は、このトポロジを使用します。

重要な構成の側面

• 高可用性とフェールオーバーのために、2 つのプロビジョニング エージェント ノードを設定します。
• プロビジョニング エージェント構成ウィザードを使用して、AD ドメインを Microsoft Entra テナントに登録します。
• プロビジョニング アプリを構成するときに、登録されているドメインのドロップダウンから AD ドメインを選択します。
• スコープ フィルターを使用している場合は、誤ってアカウントが非アクティブ化されないように、 スコープ外の削除フラグ を構成します。

デプロイ トポロジ 2: クラウド人事から 1 つのオンプレミスの Active Directory ドメインに個別のユーザー セットをプロビジョニングする個別のアプリ

このトポロジでは、ユーザーの種類 (従業員または請負業者)、ユーザーの所在地、またはユーザーの事業単位に基づいて、属性マッピングとプロビジョニング ロジックの異なるビジネス要件がサポートされます。 また、このトポロジを使用して、部門または国やリージョンに基づいて受信ユーザー プロビジョニングの管理と保守を委任することもできます。

重要な構成の側面

• 高可用性とフェールオーバーのために、2 つのプロビジョニング エージェント ノードを設定します。
• プロビジョニングする個別のユーザー セットごとに HR2AD プロビジョニング アプリを作成します。
• プロビジョニング アプリで スコープ フィルターを 使用して、各アプリを処理するユーザーを定義します。
• マネージャーの参照を個別のユーザー セット間で解決する必要があるシナリオでは、個別の HR2AD プロビジョニング アプリを作成します。 たとえば、請負業者は従業員であるマネージャーに報告します。 別のアプリを使用して 、マネージャー 属性のみを更新します。 このアプリのスコープをすべてのユーザーに設定します。
• 誤ってアカウントが非アクティブ化されないように、 スコープ外の削除フラグ を構成します。

デプロイ トポロジ 3: クラウド人事から複数のオンプレミスの Active Directory ドメインに個別のユーザー セットをプロビジョニングする個別のアプリ (ドメイン間の可視性なし)

トポロジ 3 を使用して、同じフォレストに属する複数の独立した子 AD ドメインを管理します。 マネージャーは常にユーザーと同じドメインに存在するようにしてください。 また、 userPrincipalName、 samAccountName、 メール などの属性の一意の ID 生成規則で、フォレスト全体の参照が必要ないことを確認します。 トポロジ 3 には、各プロビジョニング ジョブの管理をドメイン境界ごとに委任することができる柔軟性も備わっています。

たとえば、この図では、プロビジョニング アプリは、北米 (NA)、ヨーロッパ、中東およびアフリカ (EMEA)、アジア太平洋 (APAC) の各リージョンに設定されています。 場所に応じて、ユーザーはそれぞれの AD ドメインにプロビジョニングされます。 EMEA 管理者が EMEA リージョンに属するユーザーのプロビジョニング構成を個別に管理できるように、プロビジョニング アプリの委任された管理が可能です。

重要な構成の側面

• 高可用性とフェールオーバーのために、2 つのプロビジョニング エージェント ノードを設定します。
• プロビジョニング エージェント構成ウィザードを使用して、すべての子 AD ドメインを Microsoft Entra テナントに登録します。
• ターゲット ドメインごとに個別の HR2AD プロビジョニング アプリを作成します。
• プロビジョニング アプリを構成するときに、使用可能な AD ドメインのドロップダウンからそれぞれの子 AD ドメインを選択します。
• プロビジョニング アプリで スコープ フィルターを 使用して、各アプリが処理するユーザーを定義します。
• 誤ってアカウントが非アクティブ化されないように、 スコープ外の削除フラグ を構成します。

デプロイ トポロジ 4: クラウド人事から複数のオンプレミスの Active Directory ドメインに個別のユーザー セットをプロビジョニングする個別のアプリ (ドメイン間の可視性あり)

トポロジ 4 を使用して、同じフォレストに属する複数の独立した子 AD ドメインを管理します。 ユーザーのマネージャーが別のドメインに存在する場合があります。 また、 userPrincipalName、 samAccountName 、 メール などの属性に対する一意の ID 生成規則には、フォレスト全体の検索が必要です。

たとえば、この図では、プロビジョニング アプリは、北米 (NA)、ヨーロッパ、中東およびアフリカ (EMEA)、アジア太平洋 (APAC) の各リージョンに設定されています。 場所に応じて、ユーザーはそれぞれの AD ドメインにプロビジョニングされます。 ドメイン間マネージャーの参照とフォレスト全体の検索は、プロビジョニング エージェントで参照の追跡を有効にすることで処理されます。

重要な構成の側面

• 高可用性とフェールオーバーのために、2 つのプロビジョニング エージェント ノードを設定します。
• プロビジョニング エージェントで追跡を設定します。
• プロビジョニング エージェント構成ウィザードを使用して、親 AD ドメインとすべての子 AD ドメインを Microsoft Entra テナントに登録します。
• ターゲット ドメインごとに個別の HR2AD プロビジョニング アプリを作成します。
• それぞれのプロビジョニング アプリを構成するときに、使用可能な AD ドメインのドロップダウンから親 AD ドメインを選択します。 親ドメインを選択すると、 userPrincipalName、 samAccountName 、 mail などの属性の一意の値を生成しながら、フォレスト全体の参照が保証されます。
• parentDistinguishedName と式マッピングを使用して、適切な子ドメインと OU コンテナーにユーザーを動的に作成します。
• プロビジョニング アプリで スコープ フィルターを 使用して、各アプリが処理するユーザーを定義します。
• クロスドメイン マネージャーの参照を解決するには、 マネージャー 属性のみを更新するための個別の HR2AD プロビジョニング アプリを作成します。 このアプリのスコープをすべてのユーザーに設定します。
• 誤ってアカウントが非アクティブ化されないように、 スコープ外の削除フラグ を構成します。

デプロイ トポロジ 5: 1 つのアプリで、クラウド HR からすべてのユーザーを複数のオンプレミスの Active Directory ドメインにプロビジョニングする (ドメイン間の可視性あり)

1 つのプロビジョニング アプリを使用して、すべての親と子 AD ドメインに属するユーザーを管理する場合は、このトポロジを使用します。 プロビジョニング ルールがすべてのドメインで一貫性があり、プロビジョニング ジョブの委任管理の要件がない場合は、このトポロジをお勧めします。 このトポロジは、ドメイン間マネージャーの参照の解決をサポートしており、フォレスト全体の一意性の確認を実行できます。

たとえば、この図では、1 つのプロビジョニング アプリで、北米 (NA)、ヨーロッパ、中東およびアフリカ (EMEA)、アジア太平洋 (APAC) のリージョン別にグループ化された 3 つの異なる子ドメインに存在するユーザーを管理しています。 parentDistinguishedName の属性マッピングは、適切な子ドメインにユーザーを動的に作成するために使用されます。 ドメイン間マネージャーの参照とフォレスト全体の検索は、プロビジョニング エージェントで参照の追跡を有効にすることで処理されます。

重要な構成の側面

• 高可用性とフェールオーバーのために、2 つのプロビジョニング エージェント ノードを設定します。
• プロビジョニング エージェントで追跡を設定します。
• プロビジョニング エージェント構成ウィザードを使用して、親 AD ドメインとすべての子 AD ドメインを Microsoft Entra テナントに登録します。
• フォレスト全体に対して 1 つの HR2AD プロビジョニング アプリを作成します。
• プロビジョニング アプリを構成するときに、使用可能な AD ドメインのドロップダウンから親 AD ドメインを選択します。 親ドメインを選択すると、 userPrincipalName、 samAccountName 、 mail などの属性の一意の値を生成しながら、フォレスト全体の参照が保証されます。
• parentDistinguishedName と式マッピングを使用して、適切な子ドメインと OU コンテナーにユーザーを動的に作成します。
• スコープ フィルターを使用している場合は、誤ってアカウントが非アクティブ化されないように、 スコープ外の削除フラグ を構成します。

デプロイ トポロジ 6: 個別のアプリで、クラウド HR から個別のユーザーを接続解除されたオンプレミスの Active Directory フォレストにプロビジョニングする

IT インフラストラクチャが AD フォレストを接続解除または分離し、事業所属に基づいてユーザーを別のフォレストにプロビジョニングする必要がある場合は、このトポロジを使用します。 たとえば、子会社 Contoso に勤務するユーザーは contoso.com ドメインにプロビジョニングする必要があります。一方、子会社 Fabrikam に勤務するユーザーは 、fabrikam.com ドメインにプロビジョニングする必要があります。

重要な構成の側面

• 高可用性とフェールオーバーのために、フォレストごとに 1 つずつ、2 つの異なるプロビジョニング エージェント セットを設定します。
• フォレストごとに 1 つずつ、2 つの異なるプロビジョニング アプリを作成します。
• フォレスト内のクロスドメイン参照を解決する必要がある場合は、プロビジョニング エージェントでリファラーチェイシングを有効にします。
• 接続解除されたフォレストごとに個別の HR2AD プロビジョニング アプリを作成します。
• それぞれのプロビジョニング アプリを構成するときに、使用可能な AD ドメイン名のドロップダウンから適切な親 AD ドメインを選択します。
• 誤ってアカウントが非アクティブ化されないように、 スコープ外の削除フラグ を構成します。

デプロイ トポロジ 7: 個別のアプリで、複数のクラウド HR から個別のユーザーを接続解除されたオンプレミスの Active Directory フォレストにプロビジョニングする

大規模な組織では、複数の人事システムを使用することも珍しくありません。 企業の M&A (合併と買収) のシナリオでは、オンプレミスの Active Directory を複数の人事ソースに接続する必要がある場合があります。 複数の人事ソースを持ち、これらの人事ソースから同じまたは異なるオンプレミスの Active Directory ドメインに ID データを送る場合は、このトポロジをお勧めします。

重要な構成の側面

• 高可用性とフェールオーバーのために、フォレストごとに 1 つずつ、2 つの異なるプロビジョニング エージェント セットを設定します。
• フォレスト内のクロスドメイン参照を解決する必要がある場合は、プロビジョニング エージェントでリファラーチェイシングを有効にします。
• 各人事システムとオンプレミスの Active Directory の組み合わせごとに個別の HR2AD プロビジョニング アプリを作成します。
• それぞれのプロビジョニング アプリを構成するときに、使用可能な AD ドメイン名のドロップダウンから適切な親 AD ドメインを選択します。
• 誤ってアカウントが非アクティブ化されないように、 スコープ外の削除フラグ を構成します。

スコープ フィルターと属性マッピングの計画

クラウド人事アプリから Active Directory または Microsoft Entra ID へのプロビジョニングを有効にすると、Microsoft Entra 管理センターは属性マッピング経由で属性値を制御します。

スコープ フィルターの定義

スコープ フィルターを使用して、クラウド人事アプリから Active Directory または Microsoft Entra ID にプロビジョニングする必要があるユーザーを決定する属性ベースのルールを定義します。

入社プロセスを開始するときに、次の要件を収集します。

• クラウド人事アプリを社員と臨時社員両方のオンボードに使用しているか。
• クラウド人事アプリから Microsoft Entra へのユーザー プロビジョニングを使用して、従業員と臨時労働者の両方を管理することを計画しているか。
• クラウド人事アプリのユーザーの一部のみを対象に、クラウド人事アプリから Microsoft Entra へのユーザー プロビジョニングを実行することを計画しているか。 例として、社員のみが考えられます。

要件に応じて、属性マッピングを構成するときに、[ ソース オブジェクト スコープ ] フィールドを設定して、Active Directory へのプロビジョニングのスコープに含めるクラウド HR アプリ内のユーザーのセットを選択できます。 一般的に使用されるスコープ フィルターの詳細については、クラウド人事アプリのチュートリアルを参照してください。

一致属性の決定

プロビジョニングでは、ソース システムとターゲット システムの間で既存のアカウントを一致させることができます。 クラウド人事アプリを Microsoft Entra プロビジョニング サービスと統合する場合は、 属性マッピングを構成 して、クラウド人事アプリから Active Directory または Microsoft Entra ID にフローするユーザー データを決定できます。

入社プロセスを開始するときに、次の要件を収集します。

• 各ユーザーの識別に使われる、このクラウド人事アプリでの一意 ID は何か。
• ID のライフサイクルの観点から、再雇用をどのように処理するか。 再雇用時に古い社員 ID が保持されるか。
• 将来の日付の雇用を処理し、対象者の Active Directory アカウントを事前に作成するか。
• ID のライフサイクルの観点から、社員から臨時社員への (またはその逆の) 転換をどのように処理するか。
• 変換されたユーザーが、古い Active Directory アカウントを保持するか、それとも新しいアカウントを取得するか。

要件に応じて、Microsoft Entra ID では、定数値を指定するか、属性マッピングの式を記述することで、 属性から属性への直接マッピングがサポートされます。 この柔軟性により、ターゲット アプリの属性に設定される内容を完全に制御できます。 Microsoft Graph API と Graph Explorer を使用して、ユーザー プロビジョニング属性マッピングとスキーマを JSON ファイルにエクスポートし、Microsoft Entra ID にインポートし直すことができます。

既定では、一意の従業員 ID を表すクラウド人事アプリの属性は、 Active Directory の一意の属性にマップされた 一致する属性として使用されます。たとえば、Workday アプリのシナリオでは、 WorkdayWorkerID 属性が Active Directory employeeID 属性にマップされます。

複数の一致属性を設定し、一致の優先順位を割り当てることができます。 一致の優先順位に従って評価が行われます。 1 件でも一致が見つかると、一致する属性の評価はそれ以上行われません。

既存 の属性マッピングの変更や削除など、既定の属性マッピングをカスタマイズすることもできます。 また、ビジネスのニーズに合わせて新しい属性マッピングを作成できます。 詳細については、マップするカスタム属性の一覧については、クラウド人事アプリのチュートリアル ( Workday など) を参照してください。

ユーザー アカウントの状態の決定

既定では、プロビジョニング コネクタ アプリは、人事のユーザー プロファイルの状態をユーザー アカウントの状態にマッピングします。 状態は、ユーザー アカウントを有効または無効にするかどうかを決定するために使用されます。

入社および退職プロセスを開始するときに、次の要件を収集します。

要件に応じて、 Microsoft Entra 式 を使用してマッピング ロジックをカスタマイズし、データ ポイントの組み合わせに基づいて Active Directory アカウントを有効または無効にできます。

クラウド人事アプリを Active Directory ユーザー属性にマップする

クラウド人事アプリごとに、クラウド人事アプリから Active Directory への既定のマッピングが存在します。

入社、異動、退職プロセスを開始するときに、次の要件を収集します。

要件に応じて、統合の目標を満たすようにマッピングを変更できます。 詳細については、マップするカスタム属性の一覧については、特定のクラウド人事アプリのチュートリアル ( Workday など) を参照してください。

一意の属性値の生成

CN、samAccountName、UPN などの属性には、一意の制約があります。 入社プロセスを開始する際に、一意の属性値を生成する必要がある場合があります。

Microsoft Entra ID 関数 SelectUniqueValues は、各ルールを評価し、生成された値がターゲット システムで一意であることを確認します。 例については、「 userPrincipalName (UPN) 属性の一意の値を生成する」を参照してください。

Active Directory OU コンテナーの割り当てを構成する

事業単位、所在地、部門に基づいて Active Directory ユーザー アカウントをコンテナーに配置することは一般的な要件です。 異動プロセスを開始し、監督組織の変更があった場合、Active Directory 内で、ある OU から別の OU にユーザーを移動することが必要な場合があります。

Switch() 関数を使用して OU 割り当てのビジネス ロジックを構成し、Active Directory 属性 parentDistinguishedName にマップします。

たとえば、HR 属性 市区町村に基づいて OU にユーザーを作成する場合は、次の式を使用できます。

Switch([Municipality], "OU=Default,OU=Users,DC=contoso,DC=com", "Dallas", "OU=Dallas,OU=Users,DC=contoso,DC=com", "Austin", "OU=Austin,OU=Users,DC=contoso,DC=com", "Seattle", "OU=Seattle,OU=Users,DC=contoso,DC=com", "London", "OU=London,OU=Users,DC=contoso,DC=com")

この式では、Municipality の値が Dallas、Austin、Seattle、または London の場合、ユーザー アカウントは対応する OU に作成されます。 一致するものがない場合、アカウントは既定の OU に作成されます。

新しいユーザー アカウントのパスワード交付の計画

入社プロセスの開始時に、新しいユーザー アカウントの一時パスワードを設定して交付する必要があります。 クラウド HR から Microsoft Entra へのユーザー プロビジョニングを使用すると、1 日目にユーザーの Microsoft Entra ID セルフサービス パスワード リセット (SSPR) 機能をロールアウトできます。

SSPR は、パスワードのリセットやアカウントのロック解除を IT 管理者がユーザーに許可するための簡単な手段です。 クラウド人事アプリから Active Directory に Mobile Number 属性をプロビジョニングし、Microsoft Entra ID と同期することができます。 Mobile Number 属性が Microsoft Entra ID に設定されたら、ユーザーのアカウントに対して SSPR を有効にすることができます。 その後、新しいユーザーは初日に認証に登録および検証された携帯電話番号を使用できます。 認証の連絡先情報を事前入力する方法の詳細については 、SSPR のドキュメント を参照してください。

初期サイクルの計画

Microsoft Entra プロビジョニング サービスを初めて実行すると、クラウド HR アプリに対して 最初のサイクル が実行され、クラウド HR アプリ内のすべてのユーザー オブジェクトのスナップショットが作成されます。 初期サイクルにかかる時間は、ソース システムに存在するユーザーの数に正比例します。 ユーザーが 10 万人を超えるようなクラウド人事アプリのテナントでは、初期サイクルに長い時間がかかることがあります。

大規模なクラウド人事アプリ テナント (>30,000 ユーザー) の場合は、 初期サイクルを段階的な段階で実行します。 増分更新を開始するのは、異なるユーザー プロビジョニングのシナリオに応じて Active Directory で正しい属性が設定されていることを検証した後のみにしてください。 この順序に従ってください。

1. スコープ フィルターを設定して、限られたユーザーのセットに対してのみ初期サイクルを実行します。
2. 最初の実行のために選択したユーザーについて、Active Directory アカウントのプロビジョニングと属性値の設定を確認します。 結果が期待どおりである場合、スコープ フィルターを拡張してユーザーを徐々に増やし、2 回目の実行の結果を確認します。

テスト ユーザーの初期サイクルの結果に満足したら、 増分更新を開始します。

テストとセキュリティを計画する

デプロイは、初期パイロットからユーザー プロビジョニングを有効にするまでのステージで構成されます。 各段階で、期待される結果を得るためのテストが行われていることを確認します。 また、プロビジョニング サイクルを監査します。

テストを計画する

クラウド人事アプリから Microsoft Entra へのユーザー プロビジョニングを構成したら、テスト ケースを実行して、このソリューションが組織の要件を満たしているかどうかを確認します。

以上の結果を用いて、また確定したスケジュールに基づいて、自動ユーザー プロビジョニングの実装を運用環境に移行する方法を決定します。

セキュリティを計画する

通常、新しいサービスのデプロイの一環としてセキュリティ レビューが必要になります。 セキュリティ レビューが必要な場合、または実施されていない場合は、サービスとしての ID の概要を示す多くの Microsoft Entra ID ホワイト ペーパー を参照してください。

ロールバックを計画する

クラウドの人事ユーザー プロビジョニングの実装は、運用環境では期待通りに動作しない可能性があります。 その場合、次のロールバック手順を使用すると、以前の正常な状態に戻すことができます。

1. プロビジョニング ログを確認して、影響を受けたユーザーまたはグループに対して実行された不適切な操作を確認します。 プロビジョニングの概要レポートとログの詳細については、「 クラウド人事アプリのユーザー プロビジョニングの管理」を参照してください。
2. 影響を受けるユーザーやグループの最後の既知の良好な状態は、プロビジョニング ログ経由で、またはターゲット システム (Microsoft Entra ID または Active Directory) を確認することで判定できます。
3. アプリの所有者と協力し、最新の既知の正常な状態の値を使用して、アプリで直接影響を受けたユーザーやグループを更新します。

クラウド人事アプリのデプロイ

ソリューションの要件に合ったクラウド人事アプリを選択します。

Workday: Workday から Active Directory と Microsoft Entra ID に worker プロファイルをインポートするには、「 チュートリアル: Workday を構成して自動ユーザー プロビジョニングを行う」を参照してください。 必要に応じて、メール アドレス、ユーザー名、電話番号を Workday に書き戻すことができます。

SAP SuccessFactors: SuccessFactors から Active Directory と Microsoft Entra ID に worker プロファイルをインポートするには、「 チュートリアル: SAP SuccessFactors を構成して自動ユーザー プロビジョニングを行う」を参照してください。 必要に応じて、メール アドレスとユーザー名を SuccessFactors に書き戻すことができます。

構成の管理

Microsoft Entra ID は、プロビジョニング ログとレポートを介して、組織のユーザー プロビジョニングの使用状況と運用の正常性について追加の分析情報を提供します。

レポートとログから分析情報を得る

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

• サービスは手動で停止されます。 Microsoft Entra 管理センターまたは適切な Microsoft Graph API コマンドを使用して、新しい初期サイクルがトリガーされます。
• 属性マッピングまたはスコープ フィルターの変更によって、新しい初期サイクルがトリガーされます。
• エラー率が高いため、プロビジョニング プロセスは検査に入ります。 4 週間を超えると、検査は自動的に無効になります。

これらのイベントとプロビジョニング サービスによって実行されるその他のすべてのアクティビティを確認するには、 ログを確認し、プロビジョニング アクティビティに関するレポートを取得する方法について説明します。

Azure Monitor ログ

プロビジョニング サービスによって実行されたアクティビティはすべて、Microsoft Entra のプロビジョニング ログに記録されます。 Microsoft Entra プロビジョニング ログを Log Analytics ワークスペースにルーティングできます。これにより、データを Azure Monitor ログと Microsoft Entra ブックに送信し、データのクエリを行ってイベントを検索し、傾向を分析して、さまざまなデータ ソース間の相関を実行できます。 この ビデオ では、実際のユーザー シナリオで Microsoft Entra ログに Azure Monitor ログを使用する利点について説明します。

Log Analytics と Microsoft Entra のブックを有効にするには、Log Analytics ワークスペースを構成する必要があります。 次に、診断設定を構成して、適切なエンドポイントにデータをルーティングします。 詳細については、以下を参照してください:

• Log Analytics ワークスペースを構成する
• Microsoft Entra アクティビティ ログを Azure Monitor ログと統合する
• Microsoft Entra ワークブックを使用する方法
• プロビジョニング インサイト ワークブック

個人データを管理する

Windows サーバーにインストールされた Microsoft Entra Connect プロビジョニング エージェントは、Windows イベント ログにログを作成しますが、これには、クラウド人事アプリから Active Directory への属性マッピングの設定によっては、個人データが含まれる場合があります。 ユーザーのプライバシー義務を遵守するために、イベント ログを消去するように Windows のスケジュールされたタスクを設定し、48 時間を超えてデータが保持されないようにすることができます。

Microsoft Entra プロビジョニング サービスは、30 日を超えたレポートの生成、分析の実行、分析情報の提供を行いません。サービスが 30 日を超えてデータを格納、処理、保持しないためです。

Joiner-Mover-Leaver ライフサイクル ワークフローの管理

人事主導のプロビジョニング プロセスを拡張して、新規採用、人事上の変更、退職に関連するビジネス プロセスとセキュリティ制御をさらに自動化できます。 Microsoft Entra ID ガバナンス ライフサイクル ワークフローでは、次のような JoinerMover-Leaver ワークフローを構成できます。

• 新規採用者が入社する日の "X" 日前に、マネージャーに電子メールを送信し、ユーザーをグループに追加し、初回ログインの一時的なアクセス パスを生成します。
• ユーザーの部署または役職またはグループ メンバーシップに変更がある場合は、カスタム タスクを起動します。
• 在籍最終日に、マネージャーに電子メールを送信し、グループとライセンスの割り当てからユーザーを削除します。
• 退職の "X" 日後、Microsoft Entra ID からユーザーを削除します。

トラブルシューティング

プロビジョニング中に発生する可能性がある問題のトラブルシューティングについては、次の記事を参照してください。

• Microsoft Entra Gallery アプリケーションへのユーザー プロビジョニングの構成に関する問題
• オンプレミスの Active Directory から Microsoft Entra ID に属性を同期してアプリケーションにプロビジョニングする
• Microsoft Entra Gallery アプリケーションへのユーザー プロビジョニングの構成中に管理者の資格情報を保存する際の問題
• Microsoft Entra Gallery アプリケーションにユーザーがプロビジョニングされていない
• Microsoft Entra Gallery アプリケーションにプロビジョニングされているユーザーのセットが間違っている
• エージェントのトラブルシューティングのための Windows イベント ビューアーの設定
• サービスのトラブルシューティングのための Microsoft Entra 管理センターのプロビジョニング ログの設定
• AD ユーザー アカウントの作成操作のログについて
• Manager の更新操作のログについて
• 一般的に発生するエラーの解決

次のステップ

• 属性マッピングの式の記述
• Microsoft Entra 同期 API の概要
• スコープ外のユーザー アカウントの削除をスキップする
• Microsoft Entra Connect プロビジョニング エージェント: バージョンのリリース履歴