SAP ソースアプリケーションとターゲットアプリケーションを使用したユーザープロビジョニングのために Microsoft Entra のデプロイを計画する

[アーティクル]
08/14/2024

組織は、さまざまな Azure サービスや Microsoft 365 について Microsoft に依存しています。 SAP ソフトウェアとサービスは、組織の人事 (HR) やエンタープライズリソースプランニング (ERP) などの重要な機能も提供する場合があります。 Microsoft Entra を使用して、従業員、請負業者、およびその他のユーザーの ID と、SAP および非 SAP アプリケーション全体のアクセスを調整できます。

このチュートリアルでは、Microsoft Entra 機能を使用して、SAP 人事ソースから送信されたそれらの ID のプロパティに基づいて SAP アプリケーション全体で ID を管理する方法について説明します。このチュートリアルでは、次のことを前提としています:

組織には商用クラウドに Microsoft Entra テナントがあり、そのテナントの Microsoft Entra ID P1 以上のライセンスがあること。 (一部のステップでは、Azure AD Identity Governance 機能の使用も示しています。)
あなたがそのテナントの管理者であること。
組織に worker のレコードソースシステム "SAP SuccessFactors" があること。
組織に SAP ERP Central Component (ECC)、SAP S/4HANA、または他の SAP アプリケーションがあり、オプションとして他の SAP 以外のアプリケーションがあること。
SAP ECC 以外の SAP アプリケーションへのプロビジョニングとシングルサインオン (SSO) には、SAP Cloud Identity Services を使用しています。

概要

このチュートリアルでは、Microsoft Entra を、SAP SuccessFactors などの組織内の worker の一覧の権限のあるソースと接続する方法について説明します。また、Microsoft Entra を使用してこれらの worker の ID を設定する方法についても説明します。次に、Microsoft Entra を使用して、SAP ECC や SAP S/4HANA などの 1 つ以上の SAP アプリケーションにサインインするためのアクセス権を worker に提供する方法について説明します。

プロセスは以下のとおりです。

プラン: 組織内のアプリケーションの ID とアクセスの要件を定義します。 Microsoft Entra ID と関連する Microsoft Online Services がこのシナリオの組織の前提条件を満たしていることを確認します。
展開: 必要なユーザーを Microsoft Entra ID に取り込み、適切な資格情報を使用してそれらのユーザーを最新の状態に保つプロセスを作成します。 Microsoft Entra で必要なアクセス権を持つユーザーを割り当てます。それらのアプリケーションへのユーザーとそのアクセス権をプロビジョニングし、それらのアプリケーションにサインインできるようにします。
監視: ID フローを監視してエラーがないかを確認し、必要に応じてポリシーや操作を調整します。

プロセスが完了すると、個人は、Microsoft Entra ユーザー ID で使用する権限を持つ SAP および SAP 以外のアプリケーションにサインインできます。

次の図は、このチュートリアルで使用するトポロジの例を示したものです。このトポロジでは、worker は SuccessFactors で表され、Windows Server Active Directory (Windows Server AD) ドメイン、Microsoft Entra、SAP ECC、SAP クラウドアプリケーションにアカウントがある必要があります。このチュートリアルでは、Windows Server AD ドメインを持つ組織について説明します。ただし、このチュートリアルでは Windows Server AD は必要ありません。

このチュートリアルでは、従業員や他の worker を表すユーザーの ID ライフサイクルに焦点を当てます。ゲストの ID ライフサイクルと、ロールの割り当て、要求、レビューのアクセスライフサイクルは、このチュートリアルでは扱いません。

SAP ソースとターゲットとの統合を計画する

このセクションでは、組織内のアプリケーションの ID とアクセスの要件を定義します。このセクションでは、SAP アプリケーションとの統合に必要な主な決定事項を重点的に取り上げます。 SAP 以外のプリケーションについては、それらのアプリケーションへのアクセスを制御するための組織ポリシーを定義することもできます。

これまで SAP IDM を使ってきた場合は、ID 管理シナリオを SAP IDM から Microsoft Entra に移行できます。詳しくは、「ID 管理シナリオの SAP IDM から Microsoft Entra への移行」をご覧ください。

アプリケーションオンボードのシーケンスと、アプリケーションと Microsoft Entra の統合方法を決定する

おそらく組織では、使用可能な統合シナリオのサブセットのために、一部のアプリケーションが Microsoft Entra と既に統合されているでしょう。たとえば、SAP Cloud Identity Services と Microsoft Entra for SSO を統合して条件付きアクセスの利点を得たとしても、手動プロビジョニングとプロビジョニング解除に依存している可能性があります。または、Microsoft Entra とまだ統合していない SAP ECC などのアプリケーションが組織内にある場合もあります。

SSO とプロビジョニングのために、アプリケーションを Microsoft Entra と統合するための優先順位を確立します。 通常、組織は最新のプロトコルをサポートするサービスとしてのソフトウェア (SaaS) アプリケーションとの統合を最初に行います。 SAP アプリケーションについては、SAP クラウドアプリケーションを持つ組織が、SAP Cloud Identity Services をミドルウェアとして使用して、SSO とプロビジョニングの統合から開始することをお勧めします。ここでは、ユーザープロビジョニングと SSO を Microsoft Entra に統合すると、複数の SAP アプリケーションにメリットがあります。
各アプリケーションを Microsoft Entra と統合する方法を確認します。 アプリケーションが SAP Cloud Identity Services のプロビジョニングターゲットシステムの 1 つとして記載されている場合 (SAP S/4HANA など)、SAP Cloud Identity Services をミドルウェアとして使用して、SSO とプロビジョニングを Microsoft Entra からアプリケーションに移行します。アプリケーションが SAP ECC の場合は、Microsoft Entra と SAP NetWeaver for SSO を直接統合し、プロビジョニングのために SAP ECC のビジネスアプリケーションプログラミングインターフェイス (BAPI) に統合できます。

SAP 以外のアプリケーションの場合、「Microsoft Entra ID とアプリケーションの統合」の指示に従って、各アプリケーションの SSO とプロビジョニングでサポートされる統合テクノロジを特定します。
各アプリケーションが提供するロールとアクセス許可を収集します。 一部のアプリケーションには、1 つのロールしかありません。たとえば、SAP Cloud Identity Services には、割り当てに使用できるユーザー ロールが 1 つだけ含まれます。 SAP Cloud Identity Services では Microsoft Entra ID からグループを読み取ってアプリケーションの割り当てに使用できます。他のアプリケーションでは、Microsoft Entra ID を通して管理される複数のロールが表示される場合があります。通常、これらのアプリケーションロールは、そのロールを持つユーザーがアプリ内で持つアクセスに大きな制約を与えます。

また、他のアプリケーションは、グループメンバーシップまたは要求に依存して、より詳細なロールチェックを行う場合もあります。これらは、フェデレーション SSO プロトコルを使用して発行されたプロビジョニングまたは要求で、Microsoft Entra ID から各アプリケーションに提供できます。また、セキュリティグループメンバーシップとして Active Directory に書き込むこともできます。

Note

プロビジョニングをサポートする Microsoft Entra ID アプリケーションギャラリーのアプリケーションを使用している場合、プロビジョニングが構成された後に、Microsoft Entra ID によって定義されたロールがアプリケーションにインポートされ、アプリケーションのロールを使用してアプリケーションマニフェストが自動的に更新される場合があります。
Microsoft Entra ID で管理されるメンバーシップを持つロールとグループを選びます。 多くの場合、コンプライアンスとリスク管理の要件に基づいて、組織は、機密情報への特権アクセスまたはアクセスを許可するアプリケーションロールまたはグループに優先順位を付けます。このチュートリアルでアクセスの割り当てを構成する手順は扱いませんが、すべてのメンバーがアプリケーションに確実にプロビジョニングされるように、関連するロールとグループを特定する必要がある場合があります。

アプリケーションへのアクセスに関するユーザーの前提条件とその他の制約について組織のポリシーを定義する

このセクションでは、各アプリケーションへのアクセスを決定するために使用する予定の組織ポリシーを決定します。

アプリケーションへのアクセス権を付与される前に、ユーザーが満たす必要がある前提条件、標準があるかどうかを特定します。 コンプライアンス要件またはリスク管理計画がある組織には、機密性の高いアプリケーションまたはビジネスクリティカルなアプリケーションがあります。 Microsoft Entra ID と統合する前に、これらのアプリケーションにアクセスできるユーザーのアクセスポリシーを既に文書化している可能性があります。そうでない場合は、コンプライアンスチームやリスク管理チームなどの利害関係者と相談する必要があります。アクセスの決定を自動化するために使用されるポリシーがシナリオに適していることを確認する必要があります。

たとえば、通常の状況では、フルタイムの従業員や、特定の部門またはコストセンターの従業員のみが、特定の部門のアプリケーションへのアクセスを既定で許可される必要があります。 Azure AD Identity Governance で Microsoft Entra エンタイトルメント管理を使用している場合は、アクセス権を要求している他の部門のユーザーに対して 1 人以上の承認者を得るようにエンタイトルメント管理ポリシーを構成して、それらのユーザーが例外としてアクセスできるようにすることができます。

一部の組織では、従業員によるアクセス要求に 2 つの承認段階がある場合があります。最初の段階は、ユーザーのマネージャーを要求することです。 2 番目の段階は、アプリケーションに保持されているデータを担当するリソース所有者の 1 人に要求することです。
アクセスを承認されたユーザーがアクセス権を得る期間と、そのアクセス権が取り消されるタイミングを決定します。 多くのアプリケーションでは、組織に所属しなくなるまで、ユーザーは無期限にアクセスを保持します。状況によっては、アクセスが特定のプロジェクトまたはマイルストーンに関連付けられていて、プロジェクトが終了すると、アクセス権が自動的に削除されることがあります。または、ポリシーを介してアプリケーションを使用しているユーザーが少ない場合は、そのポリシーを介したすべてのユーザーのアクセスを四半期ごとまたは年ごとにレビューするように構成し、定期的に監視されるようにすることができます。これらのシナリオには、Microsoft Entra ID Governance が必要です。
組織が既に組織のロールモデルを使ってアクセスを管理している場合は、その組織のロールモデルを Microsoft Entra ID に導入することを計画してください。ユーザーのプロパティ (役職や部署など) に基づいてアクセス権を割り当てる組織ロールモデルが定義されている場合があります。これらのプロセスにより、事前に決定されたプロジェクトの終了日がない場合でも、アクセスが不要になったときに最終的にユーザーがアクセス権を失うようにすることができます。

既に組織ロールの定義がある場合は、Microsoft Entra ID Governance に組織ロールの定義を移行できます。
職務の分離に基づく制約があるかどうかを問い合わせる。 このチュートリアルでは、アプリケーションへの基本的なアクセス権をユーザーに提供するための ID ライフサイクルに焦点を当てます。ただし、アプリケーションのオンボードを計画する場合は、適用する職務の分離に基づいて制約を特定できます。

たとえば、Western Sales と Eastern Sales という 2 つのアプリロールを持つアプリケーションがあるとします。ユーザーが販売区域ロールを一度に 1 つだけ持っていることを確認する必要があります。アプリケーションに互換性のないアプリロールのペアの一覧を含めます。その後、ユーザーが 1 つのロールを持っている場合、2 番目のロールを要求することはできません。アクセスパッケージに関する Microsoft Entra エンタイトルメント管理の非互換性設定で、これらの制約を適用できます。
各アプリケーションにアクセスするための適切な条件付きアクセスポリシーを選択します。 アプリケーションを分析し、それらを同じユーザーに対して同じリソース要件があるアプリケーションのコレクションに整理することをお勧めします。

フェデレーション SSO アプリケーションを Microsoft Entra ID と初めて統合するときは、制約を表す新しい条件付きアクセスポリシーを作成することが必要になる場合があります。多要素認証 (MFA) または場所ベースのアクセスの要件を、そのアプリケーションと後続のアプリケーションに適用する必要がある場合があります。また、条件付きアクセスで、ユーザーが使用条件に同意する必要があることを構成することもできます。

条件付きアクセスポリシーを定義する方法に関する考慮事項については、「条件付きアクセスのデプロイの計画」を参照してください。
条件の例外を処理する方法を決定します。 たとえば、通常、アプリケーションは指定された従業員のみが利用できますが、監査人またはベンダーが特定のプロジェクトに一時的にアクセスする必要がある場合があります。または、出張中の従業員が、通常はブロックされている場所 (組織がその場所に存在しないため) からのアクセスを必要とする場合があります。

このような状況で、Azure AD Identity Governance をご利用の場合、異なる段階、異なる制限期間、または異なる承認者がいる承認のためのエンタイトルメント管理ポリシーを選択することもできます。 Microsoft Entra テナントでゲストユーザーとしてサインインしているベンダーには、マネージャーがいない可能性があります。代わりに、組織のスポンサー、リソース所有者、またはセキュリティ責任者がアクセス要求を承認できます。

プロビジョニングと認証のトポロジを決定する

ユーザープロビジョニングと SSO のために Microsoft Entra と統合するアプリケーションを決定したら、権限のあるレコードソースシステムから送信されたデータに基づいて、ユーザー ID とその属性をこれらのアプリケーションに提供する方法のデータフローを決定します。

各 ID とその属性に対して権限のあるソースを選択します。 このチュートリアルでは、SAP アプリケーションへのアクセスを必要とするユーザーについて、SuccessFactors が権限のあるレコードソースシステムであることを前提としています。 SuccessFactors から Microsoft Entra ID へのクラウド人事主導のユーザープロビジョニングを構成するには、さまざまな側面をカバーする計画が必要です。これらの要因には、一致する ID の決定、属性マッピングの定義、属性変換、スコープフィルターなどがあります。

これらのテーマに関する包括的なガイドラインについては、クラウド人事デプロイ計画を参照してください。サポートされるエンティティや処理の詳細、さまざまな人事シナリオに向けて統合をカスタマイズする方法については、「SAP SuccessFactors の統合に関するリファレンス」を参照してください。また、他の ID に他の権限のあるソースがある場合があります。非常用アカウントや他の IT 管理者などの一部の ID は、Microsoft Entra ID が権限のあるソースである場合もあります。
Microsoft Entra ID に加えて、Windows Server AD にユーザーが存在するか、またはプロビジョニングする必要があるかを決定します。 Windows Server AD にユーザーが既に存在している場合があります。これは、権限のある人事ソースの worker に対応します。または、Lightweight Directory Access Protocol (LDAP) または Kerberos を介して Windows Server に依存するように SAP ECC またはその他のアプリケーションを構成した可能性があります。このような状況では、ユーザーを Windows Server AD にプロビジョニングします。その後、これらのユーザーは Microsoft Entra ID に同期されます。
Microsoft Entra Connect プロビジョニングエージェントのデプロイトポロジを設計する SuccessFactors を使用していて、Windows Server AD がある場合は、プロビジョニングエージェントをインストールして、それらのドメインにユーザーをプロビジョニングする必要があります。 Microsoft Entra Connect プロビジョニングエージェントのデプロイトポロジは、統合を計画しているクラウド人事アプリのテナントおよび Active Directory 子ドメインの数によって異なります。複数の Active Directory ドメインがある場合、Active Directory ドメインが連続しているか分離しているかによっても異なります。詳細については、「Microsoft Entra Connect プロビジョニングエージェントのデプロイトポロジを設計する」を参照してください。
Windows Server AD で複数のコンテナーを使用するかどうかを決定します。 SuccessFactors を使用していて、Windows Server AD を使用している場合は、各ドメインで、worker を表すユーザーがコンテナー階層に編成されているかどうかを判断する必要があります。一部の組織では、従業員を表すすべてのユーザーを 1 つのorganizationalUnitに作成できます。他の組織には複数のユーザーが含まれる場合があります。詳細については、「Active Directory OU コンテナーの割り当てを構成する」をご覧ください。
Microsoft Entra ID を使用して SAP Cloud Identity Services にプロビジョニングする必要があるか、SAP Cloud Identity Services を使用して Microsoft Entra ID から読み取るかを決定します。 Microsoft Entra のプロビジョニング機能の詳細については、Microsoft Entra ID での SAP Cloud Identity Services へのユーザーのプロビジョニングとプロビジョニング解除の自動化に関する記事をご覧ください。 SAP Cloud Identity Services には、Microsoft Entra ID からユーザーとグループを読み取る独自のコネクタもあります。詳しくは、「SAP Cloud Identity Services - Identity Provisioning - Microsoft Entra ID as a source system」を参照してください。
ユーザーを SAP ECC にプロビジョニングする必要があるかどうかを決定します。 Microsoft Entra ID から SAP ECC (旧 SAP R/3) NetWeaver 7.0 以降にユーザーをプロビジョニングできます。ほかのバージョンの SAP R/3 を使用している場合でも、Connectors for Microsoft Identity Manager 2016 のダウンロードで提供されているガイドを参照し、プロビジョニング用の独自のテンプレートを作成できます。

Microsoft Entra ID を構成する前に、組織の前提条件が満たされていることを確認します

Microsoft Entra ID からビジネスに不可欠なアプリケーションへのアクセスをプロビジョニングするプロセスを開始する前に、Microsoft Entra 環境が適切に構成されていることを確認する必要があります。

お使いの Microsoft Entra ID と Microsoft Online Services 環境で、アプリケーションのコンプライアンス要件に対する準備ができていることを確認します。コンプライアンスは、Microsoft、クラウドサービスプロバイダーおよび組織の間での共同責任です。
Microsoft Entra ID テナントが適切にライセンスされていることを確認します。 Microsoft Entra ID を使用してプロビジョニングを自動化するには、テナントに少なくとも Microsoft Entra ID P1 ライセンスが必要です。これは、ソースの人事アプリケーションから供給される worker やプロビジョニングされるメンバー (ゲスト以外) ユーザーが存在するためです。

さらに、ライフサイクルワークフローやその他の Azure AD Identity Governance 機能 (プロビジョニングプロセスでの Microsoft Entra エンタイトルメント管理の自動割り当てポリシーなど) を使用するには、worker に対する Azure AD Identity Governance ライセンスが必要です。これらのライセンスは、Azure AD Identity Governance または Azure AD Identity Governance Step Up for Microsoft Entra ID P2 のいずれかです。
Microsoft Entra ID が、監査ログおよび必要に応じて他のログを Azure Monitor に既に送信していることを確認します。 Microsoft Entra では監査イベントが監査ログに保存されるのは最大 30 日間であるため、Azure Monitor は省略可能ですがアプリへのアクセスの管理に有用です。監査データは、この既定の保持期間よりも長く保持できます。詳細については、「Microsoft Entra ID にレポートデータが保存される期間」を参照してください。

また、履歴監査データに対して Azure Monitor ブックとカスタムクエリとレポートを使用することもできます。 Microsoft Entra 管理センターの Microsoft Entra ID で [Workbooks] をクリックすることで、Microsoft Entra 構成をチェックしてこれが Azure Monitor を使用しているかどうかを確認できます。この統合が構成されておらず、Azure サブスクリプションがあり、少なくともセキュリティ管理者である場合は、Azure Monitor を使用するように Microsoft Entra ID を構成できます。
許可されているユーザーのみが Microsoft Entra テナントの高い特権を持つ管理者ロールに含まれるようにします。 少なくとも ID ガバナンス管理者、ユーザー管理者、アプリケーション管理者、クラウドアプリケーション管理者、または特権ロール管理者である管理者は、ユーザーとそのアプリケーションロールの割り当てを変更できます。それらのロールのメンバーシップが最近まだレビューされていない場合は、少なくとも特権ロール管理者であるユーザーが、これらのディレクトリロールのアクセスレビューが開始されていることを確認する必要があります。

また、Azure Monitor、Logic Apps、Microsoft Entra 構成の操作に必要なその他のリソースを保持するサブスクリプションの Azure ロールのユーザーが確認済みであることを確認する必要もあります。
テナントが適切に分離されていることを確認します。 組織がオンプレミスで Active Directory を使用していて、それらの AD ドメインが Microsoft Entra ID に接続されている場合は、クラウドでホストされるサービスに対する高い特権を使用する管理操作が、オンプレミスアカウントから分離されていることを確認する必要があります。オンプレミスの侵害から Microsoft 365 のクラウド環境を保護するように構成していることを確認します。
セキュリティのベストプラクティスに対して環境を評価します。 Microsoft Entra ID テナントをセキュリティで保護する方法を評価するには、「すべての分離アーキテクチャに関するベストプラクティス」を確認します。
トークンの有効期間とアプリケーションのセッション設定を文書化します。 このチュートリアルの最後では、SAP ECC または SAP Cloud Identity Services アプリケーションを Microsoft Entra for SSO に統合します。継続的なアクセスを拒否されたユーザーが、フェデレーションアプリケーションを引き続き使用できる期間は、アプリケーション自体のセッションの有効期間と、アクセストークンの有効期間によって決まります。アプリケーションセッションの有効期間は、アプリケーション自体によって異なります。アクセストークンの有効期間の制御について詳しくは、「構成可能なトークンの有効期間」を参照してください。

SAP Cloud Identity Services にアプリケーションに必要なスキーママッピングがあることを確認する

組織の各 SAP アプリケーションには、ユーザーがそれらのアプリケーションにプロビジョニングされるときに、ユーザーに特定の属性が設定されるという独自の要件がある場合があります。

SAP Cloud Identity Services を使用して SAP S/4HANA またはその他の SAP アプリケーションにプロビジョニングする場合、これらの属性を Microsoft Entra ID から SAP Cloud Identity Services 経由でそれらのアプリケーションに送信するためのマッピングが SAP Cloud Identity Services にあることを確認します。 SAP Cloud Identity Services を使用していない場合は、次のセクションに進んでください。

SAP クラウドディレクトリに、SAP クラウドアプリケーションに必要なユーザースキーマがあることを確認します。 SAP Cloud Identity Services では、構成されている各ターゲットシステムによって、SAP Cloud Identity Services に提供される ID のソースのデータモデルからターゲットの要件への変換が追加されます。 ID のモデル化を計画する方法に対応するように、SAP Cloud Identity Services でこれらの変換を変更する必要がある場合があります (特に、複数のターゲットシステムが構成されている場合)。その後、Microsoft Entra が SAP Cloud Identity Services 経由で SAP クラウドアプリケーションに提供するために必要なスキーマを記録します。

レコードソースのシステム内の作業者レコードと Microsoft Entra のユーザーの関係を定義する

アプリケーションに必要な各属性は、組織内のソースから生成される必要があります。一部の属性には、定数または他の属性から変換される値が含まれる場合があります。その他の値は、ユーザーのメールアドレスなど、Microsoft オンラインサービスによって割り当てられる場合があります。ユーザーの名前、部門、その他の組織のプロパティなどの他の属性は、通常、権限のある人事レコードシステムに由来します。適切な HR レコードが Microsoft Entra ID (Entra ID) とオンプレミスの Active Directory (AD) のユーザーに確実にマップされるように、HR および IT の各チームと協力してデータの一貫性を確保し、データクレンジングタスクを計画します。

レコードソースのシステムの変更を参加イベントと脱退イベントにマップする方法を決定します。 作業者の参加と退出のプロセスを自動化する場合は、作業者の状態情報を Microsoft Entra の属性に関連付ける必要があります。詳細については、「ユーザーアカウントの状態の決定」をご覧ください。
人事ソースに、これらの SAP アプリケーションに必要なスキーマを提供できる作業者スキーマがあることを確認します。 Microsoft Entra や別の Microsoft オンラインサービスで生成されていない必須の各属性を、ソースから入手できるプロパティ (SuccessFactors など) に追跡できることを確認します。ソースに必要なスキーマがない場合、またはこれらの属性がアプリケーションへのアクセス権を付与される 1 つ以上の ID に設定されていない場合、または Microsoft Entra が読み取りを使用できない場合は、プロビジョニングを有効にする前に、これらのスキーマ要件に対処する必要があります。
Microsoft Entra ID とレコードのシステム間の相関関係に使用されるスキーマを記録します。 SAP SuccessFactors の worker に対応する Windows Server AD または Microsoft Entra ID に既存のユーザーがいる場合があります。これらのユーザーが Microsoft Entra ID ではなく他のプロセスによって作成されていない場合は、SAP SuccessFactors 属性のリファレンスと Windows Server または Microsoft Entra ユーザースキーマを参照して、SAP SuccessFactors の worker の一意識別子を含むユーザーオブジェクトの属性を選択してください。

この属性には、worker に対応する各ユーザーに一意の値が存在する必要があります。これにより、Microsoft Entra のインバウンドプロビジョニングは worker に対して既に存在するユーザーを特定し、重複するユーザーが作成されないようにすることができます。既定の一致する属性は、従業員 ID に基づいています。 HR ソースから worker をインポートする前に、完全同期を開始する際には、従業員 ID などのこの属性の値が Microsoft Entra ID (クラウド専用ユーザーの場合) と Windows Server AD (ハイブリッドユーザーの場合) に設定されていることを確認する必要があります。その値によって各ユーザーが一意に識別されます。詳細については、「一致する属性を決定する」および「一意の属性値を生成する」をご覧ください。
関連しなくなった HR レコードをスキップするには、スコープフィルターを選択します。 HR システムには、何年も従業員ではない従業員を含む、数年の雇用データがあります。一方、IT チームが関心を持つのは、現在アクティブな従業員および新規採用者の一覧と、稼働後に発生する退職レコードのみである可能性があります。 IT チームの観点から関連性がなくなった HR レコードを除外するには、HR チームと協力して、Microsoft Entra プロビジョニングのスコープフィルターで使用できる HR レコードにフラグを追加します。詳細については、「スコープフィルターの定義」をご覧ください。
新しいユーザーのユーザー名を形成する可能性のある特殊文字の処理を計画します。 ユーザーの一意のuserPrincipalNameを作成するには、ワーカーの名と姓を使用するのが一般的な方法です。 Windows Server AD と Microsoft Entra ID では、userPrincipalName はアクセント文字を許可せず、次の文字のみを許可しますA - Z, a - z, 0 - 9, ' . - _ ! # ^ ~。関数 NormalizeDiacritics を使用してアクセント文字を処理し、適切な userPrincipalName を作成します。
HR ソースから送信される長い文字列の処理を計画します。 Microsoft Entra ID および Windows Server AD 属性の設定に使用する HR フィールドに関連付けられた長い文字列値が、HR データにあるかどうかを確認します。すべての Entra ID 属性には、最大文字列長があります。 Microsoft Entra ID 属性にマップされた HR フィールドの値にさらに多くの文字が含まれている場合、属性の更新が失敗する可能性があります。 1 つのオプションは、属性マッピングを確認し、HR システムで長い文字列値を切り捨てたり更新したりする可能性があるかどうかを確認することです。それが選択肢にならない場合は、Mid などの関数を使用して長い文字列を切り捨てるか、Switch などの関数を使用して長い値を短い値または省略形にマップすることができます。
必須属性の空の可能性がある値に対処します。 Microsoft Entra ID または Windows Server AD でアカウントを作成するときは、firstName、lastName、CN、UPN などの特定の属性を設定する必要があります。そのような属性にマップされた対応する HR フィールドが null の場合、ユーザー作成操作は失敗します。たとえば、AD の CN 属性を "表示名" にマップした場合、"表示名" がすべてのユーザーに対して設定されていない限り、エラーが発生します。 1 つのオプションは、このような必須の属性マッピングを確認し、対応するフィールドが HR に入力されていることを確認することです。式マッピングで null 値をチェックするオプションを検討することもできます。たとえば、表示名が空の場合は、名と姓を連結して表示名を作ります。

SAP ECC に必要な BAPI が Microsoft Entra で使用できる準備ができていることを確認する

Microsoft Entra プロビジョニングエージェントと汎用 Web サービスコネクタは、SAP BAPI などのオンプレミスの SOAP エンドポイントへの接続を提供します。

SAP ECC を使用せず、SAP クラウドサービスへのプロビジョニングのみを行っている場合は、次のセクションに進んでください。

プロビジョニングに必要な BAPI が公開されていることを確認します。 ユーザーの作成、更新、削除に必要な API を SAP ECC NetWeaver 7.51 で公開します。 Deploying SAP NetWeaver AS ABAP 7.pdf という名前の Connectors for Microsoft Identity Manager 2016 ファイルでは、必要な API を公開する方法について説明します。
既存の SAP ユーザーが使用できるスキーマを記録します。 SAP ECC には、レコードソースの権限のあるシステムの worker に対応する既存のユーザーが存在している可能性があります。ただし、それらのユーザーが Microsoft Entra ID によって作成されなかった場合は、worker の一意識別子として使用できるフィールドをユーザーに設定する必要があります。このフィールドは、worker に対応する各ユーザーに一意の値が存在する必要があります。その後、Microsoft Entra プロビジョニングでは、worker に既に存在するユーザーを特定し、重複するユーザーの作成を回避できます。

たとえば、SAP BAPI の BAPI_USER_GETLIST と BAPI_USER_GETDETAIL を使用している可能性があります。ソースに関連付ける一意識別子として、BAPI_USER_GETDETAIL によって返されるフィールドの 1 つを選択する必要があります。ソースの一意識別子に対応するフィールドがない場合は、別の一意識別子を使用する必要があります。たとえば、その値が各 SAP ユーザーで一意であり、Microsoft Entra ID ユーザーにも存在する場合は、SAP フィールド address.e_mail を使用する必要がある場合があります。
Microsoft Entra が SAP BAPI に供給するために必要なスキーマを記録します。 たとえば、SAP BAPI BAPI_USER_CREATE1 を使用しているかもしれません。これは、ユーザーの作成に ADDRESS、COMPANY、DEFAULTS、LOGONDATA、PASSWORD、SELF_REGISTER、USERNAME のフィールドが必要です。 Microsoft Entra ID ユーザースキーマから SAP ECC 要求へのマッピングを構成するときには、Microsoft ID ユーザー属性または定数をそれらの各フィールドにマップします。

エンドツーエンドの属性フローと変換を文書化する

アプリケーションのスキーマ要件と、レコードソースのシステムから使用可能な worker フィールドを特定しました。次に、これらのフィールドが Microsoft Entra を経由して、必要に応じて Windows Server AD と SAP Cloud Identity Services を介してアプリケーションに流れる方法のパスを文書化します。

場合によっては、アプリケーションで必要な属性が、ソースから使用可能なデータ値に直接対応していない場合があります。その後、これらの値をターゲットアプリケーションに提供する前に、値を変換する必要があります。

変換を適用できる処理段階がいくつかあります。

段階	考慮事項	詳細情報のためのリンク
レコード自体のシステム内	Microsoft Entra ID ライフサイクル管理は、レコードソースのシステムから読み取る唯一のソリューションではない可能性があります。 Microsoft Entra にデータを公開する前にデータの正規化を実行すると、同様のデータを必要とする他のソリューションにも役立つ場合があります。	レコードのシステムのシステムに関するドキュメントをご覧ください
レコードのシステムから Microsoft Entra または Windows Server AD へのインバウンドプロビジョニングフロー内	1 つ以上の SuccessFactors 属性に基づいて、Windows Server AD ユーザー属性または Microsoft Entra ID ユーザー属性にカスタム値を書き込むことができます。	カスタマイズ用の関数を使用した式
Windows Server AD から Microsoft Entra ID に同期するとき	Windows Server AD に既にユーザーがいる場合、ユーザーが Microsoft Entra ID に取り込まれるときに、それらのユーザーの属性が変換される可能性があります。	Microsoft Entra Connect で同期規則をカスタマイズする方法と Microsoft Entra クラウド同期で式ビルダーを使用する
Microsoft Entra ID から SAP Cloud Identity Services、SAP ECC、またはその他の SAP 以外のアプリケーションへのアウトバウンドプロビジョニングフロー内	アプリケーションへのプロビジョニングを構成するときに指定できる属性マッピングの種類の 1 つは、Microsoft Entra ID の 1 つ以上の属性をターゲットの属性にマッピングする式です。	カスタマイズ用の関数を使用した式
アウトバウンドフェデレーション SSO で	既定では、Microsoft ID プラットフォームにより、そのユーザーのユーザー名 (別名: ユーザープリンシパル名) を値として持つ要求を含む SAML トークンがアプリケーションに対して発行され、これによってユーザーを一意に識別することができます。 SAML トークンには、ユーザーのメールアドレスまたは表示名を含む他の要求も含まれており、要求変換関数を使用できます。	SAML トークンクレームをカスタマイズすると JSON トークンのクレームをカスタマイズする
SAP Cloud Identity Services	SAP Cloud Identity Services では、構成されている各ターゲットシステムによって、SAP Cloud Identity Services に提供される ID のソースのデータモデルからターゲットの要件への変換が追加されます。 ID のモデル化を計画する方法に対応するように、SAP Cloud Identity Services でこれらの変換を変更する必要がある場合があります (特に、複数のターゲットシステムが構成されている場合)。この方法は、属性要件が SAP Cloud Identity Services に接続されている 1 つ以上の SAP アプリケーションに固有である場合に適している場合があります。	SAP Cloud Identity Services - 変換の管理

新しい認証資格情報の発行を準備する

Windows Server AD を使用している場合、アプリケーションへのアクセスが必要で、以前に Windows Server AD ユーザーアカウントを持ったことがない worker に対して Windows Server AD 資格情報を発行することを計画してください。履歴的に、一部の組織では、ユーザーはアプリケーションリポジトリに直接プロビジョニングされていました。 Worker は、Microsoft Exchange メールボックスまたは Windows Server AD 統合アプリケーションへのアクセスが必要な場合にのみ、Windows Server AD ユーザーアカウントを受け取りました。

このシナリオでは、Windows Server AD へのインバウンドプロビジョニングを構成する場合、Microsoft Entra は Windows Server AD ユーザーアカウントを持ったことのない worker と新しい worker の両方に対して Windows Server AD にユーザーを作成します。ユーザーが Windows ドメインにサインインしている場合、ユーザーがパスワードだけではなく Windows Hello for Business に登録してより強力な認証を行うことをお勧めします。
Windows Server AD を使用していない場合、アプリケーションへのアクセスが必要で、以前に Microsoft Entra ID ユーザーアカウントを持ったことがない worker に対して Microsoft Entra ID 資格情報を発行することを計画してください。最初に Windows Server AD にではなく、Microsoft Entra ID へのインバウンドプロビジョニングを構成する場合、Microsoft Entra は Microsoft Entra ID ユーザーアカウントを持ったことのない worker と新しい worker の両方に対して Microsoft Entra にユーザーを作成します。

ユーザーがパスワードを必要とする場合は、Microsoft Entra ID セルフサービスパスワードリセット (SSPR) 機能を展開して、ユーザーがパスワードをリセットできます。 [Mobile Number] (携帯電話番号) 属性をクラウド人事アプリからプロビジョニングできます。 携帯電話番号属性が Microsoft Entra ID に追加されたら、ユーザーのアカウントに対して SSPR を有効にできます。その後、新しいユーザーは初日に認証に登録および検証された携帯電話番号を使用できます。認証の連絡先情報を事前設定する方法の詳細については、SSPR のドキュメントを参照してください。

ユーザーがより強力な認証を使用する場合は、一時アクセスパスポリシーを有効にして、新しいユーザーの一時的なアクセスパスを生成できるようにします。

ユーザーが Microsoft Entra MFA の準備ができていることを確認します。 フェデレーション経由で統合されたビジネスクリティカルなアプリケーションには、Microsoft Entra MFA を要求することをお勧めします。これらのアプリケーションの場合、ポリシーでは、ユーザーがアプリケーションへのサインインを許可する Microsoft Entra ID の前に MFA 要件を満たす必要があります。組織によっては、場所によるアクセスをブロックしたり、登録済みのデバイスからアクセスするようにユーザーに要求したりする場合もあります。

認証、場所、デバイス、使用条件に必要な条件を含む適切なポリシーが既にない場合は、条件付きアクセスのデプロイにポリシーを追加します。
新しい worker に対して一時アクセスパスを発行する準備をします。 Azure AD Identity Governance を利用していて、Microsoft Entra ID へのインバウンドプロビジョニングを構成している場合は、新しい worker に対して一時アクセスパスを発行するようにライフサイクルワークフローを構成することを計画します。

パイロットを計画する

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

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

Microsoft Entra の統合のデプロイ

このセクションでは、次の作業を行います。

権限のあるソースシステムから Microsoft Entra ID にユーザーを取り込みます。
これらのユーザーを SAP Cloud Identity Services または SAP ECC にプロビジョニングして、SAP アプリケーションにサインインできるようにします。

Windows Server AD ユーザースキーマを更新する

Windows Server AD と Microsoft Entra ID にユーザーをプロビジョニングする場合、Windows Server AD 環境と関連する Microsoft Entra エージェントが、SAP アプリケーションに必要なスキーマを使用して Windows Server AD との間でユーザーを転送する準備ができていることを確認します。

Windows Server AD を使用しない場合は、次のセクションに進んでください。

必要に応じて、Windows Server AD スキーマを拡張します。 Microsoft Entra に必要なユーザー属性と、Windows Server AD ユーザースキーマにまだ含まれていないアプリケーションごとに、組み込みの Windows Server AD ユーザー拡張機能属性を選択する必要があります。または、Windows Server AD スキーマを拡張して、Windows Server AD がその属性を保持する場所を持つ必要があります。この要件には、作業者の入社日や退職日など、自動化に使用される属性も含まれます。

たとえば、一部の組織では、extensionAttribute1 や extensionAttribute2 などの属性を使用して、これらのプロパティを保持する可能性があります。組み込みの拡張属性を使用する場合、Windows Server AD の他の LDAP ベースのアプリケーション、または Microsoft Entra ID と統合されたアプリケーションによって、これらの属性がまだ使用されていないことを確認してください。他の組織では、要件に固有の名前を持つ新しい Windows Server AD 属性 (contosoWorkerId など) を作成します。
既存の Windows Server AD ユーザーが人事ソースとの相関関係に必要な属性を持っていることを確認します。 おそらく、worker に対応する既存のユーザーが Windows Server AD に存在している可能性があります。これらのユーザーには、値が一意で、それらの worker の権限のあるレコードソースシステムのプロパティに対応する属性が必要です。

たとえば、一部の組織では、Windows Server AD で employeeId などの属性を使用します。その属性を持たないユーザーが存在する場合は、後続の統合中に考慮されない可能性があります。その後、プロビジョニングが自動化されると、Windows Server AD でユーザーが重複して作成されます。ユーザーが退出しても、元のユーザーは更新または削除されません。使用できるもの:
- Active Directory コンテナー内のすべてのユーザーを取得する Get-ADUser コマンドを使用して、ドメインに参加しているコンピューター上の PowerShell パイプライン。
- {$_.employeeId -eq $null} のようなフィルターを持つ属性がないユーザーにフィルターを適用する where-object コマンド。
- 結果のユーザーを CSV ファイルにエクスポートする export-csv コマンド。
その属性がない worker に対応するユーザーがいないことを確認します。存在する場合は、先に進む前に、Windows Server AD でそれらのユーザーを編集し、不足している属性を追加する必要があります。
Microsoft Entra ID スキーマを拡張し、Windows Server AD スキーマから Microsoft Entra ID ユーザースキーマへのマッピングを構成します。 Microsoft Entra Connect Sync を使用している場合は、「Microsoft Entra Connect Sync: Directory 拡張機能」の手順を実行して、属性を使用して Microsoft Entra ID ユーザースキーマを拡張します。 Windows Server AD の属性とそれらの属性の Microsoft Entra Connect Sync マッピングを構成します。

Microsoft Entra クラウド同期を使用している場合は、Microsoft Entra クラウド同期ディレクトリ拡張機能とカスタム属性マッピングの手順を実行して、Microsoft Entra ID ユーザースキーマを他の必要な属性で拡張します。 Windows Server AD の属性とそれらの属性の Microsoft Entra クラウド同期マッピングを構成します。ライフサイクルワークフローに必要な属性を同期していることを確認します。
Windows Server AD から Microsoft Entra ID への同期が終了するまで待ちます。 Windows Server AD からさらに多くの属性をプロビジョニングするようにマッピングを変更した場合、ユーザーに対するその変更が Windows Server AD から Microsoft Entra ID に変更されるまで待ち、ユーザーの Microsoft Entra ID 表現に Windows Server AD の属性の完全なセットが含まれるようにします。

Microsoft Entra クラウド同期を使用している場合、Microsoft Entra クラウド同期を表すサービスプリンシパルの同期ジョブを取得して、同期状態の steadyStateLastAchievedTime プロパティを監視できます。サービスプリンシパル ID がない場合、「同期スキーマを表示する」を参照してください。
Windows Server AD で必要なコンテナーを作成します。 ドメイン内の組織単位にユーザーをプロビジョニングする場合は、プロビジョニングエージェントを有効にする前に、それらの organizationalUnit コンテナーが存在することを確認します。

Microsoft Entra ID のユーザースキーマを更新する

Windows Server AD を使用している場合、Windows Server AD からのマッピングの構成の一環として、Microsoft Entra ID ユーザースキーマを既に拡張しています。この手順が完了したら、次のセクションに進みます。

Windows Server AD を使用していない場合、このセクションの手順に従って Microsoft Entra ID ユーザースキーマを拡張します。

Microsoft Entra スキーマの拡張機能を保持するアプリケーションを作成します。 Windows Server AD から同期されていないテナントの場合、スキーマの拡張機能は新しいアプリケーションの一部である必要があります。まだ作成していない場合は、スキーマの拡張機能を表すアプリケーションを作成します。このアプリケーションに、ユーザーは割り当てられません。
レコードのシステムとの相関関係の属性を特定します。 おそらく、worker に対応する Microsoft Entra ID の既存のユーザーがいる可能性があります。その後、それらのユーザーには、値が一意で、それらの worker の権限のあるレコードソースシステムのプロパティに対応する属性が必要です。

たとえば、一部の組織では、この目的のために新しい属性を持つよう Microsoft Entra ID ユーザースキーマを拡張しています。この目的で属性をまだ作成していない場合、次の手順でそれを属性として含めます。
新しい属性のための Microsoft Entra ID ユーザースキーマを拡張します。 Microsoft Entra ID ユーザースキーマにまだ含まれていない SAP アプリケーションで必要な属性ごとにディレクトリスキーマの拡張機能を作成します。これらの属性により、Microsoft Entra はユーザーに関するより多くのデータを保存することができます。拡張属性を作成することで、スキーマを拡張できます。

Microsoft Entra ID のユーザーを人事ソースの worker レコードと関連付けることができるようにする

おそらく、worker に対応する Microsoft Entra ID の既存のユーザーがいる可能性があります。その後、それらのユーザーには、値が一意で、それらの worker の権限のあるレコードソースシステムのプロパティに対応する属性が必要です。

たとえば、一部の組織では、この目的のために新しい属性を持つよう Microsoft Entra ID ユーザースキーマを拡張する場合があります。その属性を持たないユーザーが存在する場合は、後続の統合中に考慮されない可能性があります。その後、プロビジョニングが自動化されると、Windows Server AD で重複するユーザーが作成されます。ユーザーが退出しても、元のユーザーは更新または削除されません。

Microsoft Entra ID からユーザーを取得します。 worker を表す Microsoft Entra ID に既に存在するユーザーが、関連付けることができるように属性を持っていることを確認します。通常、Microsoft Entra ID の一部のユーザーは、レコードソースの権限のあるシステムの worker に対応していません。これらのユーザーには、非常用の緊急アクセス用アカウント、IT ベンダーのアカウント、ビジネスゲストが含まれます。残りのユーザーについては、関連付けに使用する一意の値を持つ属性がユーザーに既に存在する必要があります。

関連付けのないユーザーがいれば、更新やプロビジョニング解除のタイミングを逸してしまう可能性があります。 Microsoft Entra では、重複するユーザーが作成される場合もあります。たとえば、すべてのメンバーユーザー (非常用アカウントを除く) に employeeid 属性があることが要件である場合、次のスクリプトのような PowerShell コマンドパイプラインを使用してそれらのユーザーを識別できます:
```
$u = get-mguser -all -property id,displayname,userprincipalname,usertype,employeeid | Where-Object {$_.UserType -ne 'Guest' -and $_.EmployeeId -eq $null}
```

ID ガバナンス機能の前提条件を設定する

Azure AD Identity Governance 機能 (Microsoft Entra エンタイトルメント管理や Microsoft Entra ライフサイクルワークフローなど) が必要であることが特定された場合、これらの機能を展開してから、worker をユーザーとして Microsoft Entra ID に取り込みます。

必要に応じて、使用条件のドキュメントをアップロードしてください。 ユーザーがアプリケーションにアクセスする前に使用条件に同意する必要がある場合は、条件付きアクセスポリシーに含めることができるように、使用条件ドキュメントを作成してアップロードします。
必要に応じて、カタログを作成します。 既定では、管理者が最初に Microsoft Entra エンタイトルメント管理を操作すると、既定のカタログが自動的に作成されます。ただし、管理対象アプリケーションのアクセスパッケージは、指定されたカタログに含まれている必要があります。 Microsoft Entra 管理センターでカタログを作成するには、「カタログを作成する」セクションの手順に従います。

PowerShell を使用してカタログを作成するには、「Microsoft Entra ID に対して認証する」と「カタログを作成する」のセクションの手順に従います。
就職者ワークフローを作成します。 Microsoft Entra ID へのインバウンドプロビジョニングを構成している場合、新しい worker に対して一時アクセスパスを発行するタスクを含むライフサイクルワークフローの就職者ワークフローを構成します。
サインインをブロックする退職者ワークフローを作成します。Microsoft Entra ライフサイクルワークフローで、ユーザーのサインインをブロックするタスクを含む退職者ワークフローを構成します。このワークフローは、オンデマンドで実行できます。スケジュールされた退職日を過ぎると worker のサインインがブロックされるようにレコードのソースからのインバウンドプロビジョニングを構成しなかった場合、それらの worker のスケジュールされた退職日に対して実行する退職者ワークフローを構成します。
ユーザーアカウントを削除する退職者ワークフローを作成します。 必要に応じて、ユーザーを削除するタスクを含む退職者ワークフローを構成します。このワークフローは、worker のスケジュールされた退職日から 30 日や 90 日後など、ある期間実行するようにスケジュールします。

Microsoft Entra ID のユーザーを人事ソースから作業者レコードに接続する

このセクションでは、Microsoft Entra ID と SAP SuccessFactors を人事ソースシステムのレコードとして統合する方法について説明します。

サービスアカウントを使用してレコードのシステムを構成し、Microsoft Entra ID に適切なアクセス許可を付与します。 SAP SuccessFactors を使用している場合、「統合のための SuccessFactors の構成」セクションの手順に従います。
レコードのシステムから Windows Server AD または Microsoft Entra ID へのインバウンドマッピングを構成します。 SAP SuccessFactors を使用しており、Windows Server AD と Microsoft Entra ID にユーザーをプロビジョニングする場合、「SuccessFactors から Active Directory へのユーザープロビジョニングの構成」のセクションの手順に従います。

SAP SuccessFactors を使用しており、Windows Server AD にプロビジョニングしない場合、「SuccessFactors から Microsoft Entra ID へのユーザープロビジョニングの構成」のセクションの手順に従います。

マッピングを構成するときは、関連付けに使用する Windows Server AD 属性または Microsoft Entra ID ユーザー属性に対して [この属性を使用してオブジェクトを照合する] を使用してマッピングを構成していることを確認します。また、作業者の入社日と退社日に必要な属性と、人事ソースから生成された宛先アプリケーションで必要なすべての属性のマッピングも構成します。
レコードのシステムからの初期インバウンドプロビジョニングを実行します。 SAP SuccessFactors を使用しており、Windows Server AD と Microsoft Entra ID にユーザーをプロビジョニングする場合、「プロビジョニングの有効化と起動」のセクションの手順に従います。 SAP SuccessFactors を使用しており、Windows Server AD にプロビジョニングしない場合、「プロビジョニングの有効化と起動」のセクションの手順に従います。大規模なクラウド HR アプリテナント (3 万人以上のユーザー）の場合、「初期サイクルの計画」で説明されているように、最初のサイクルを段階的に実行します。
レコードのシステムからの初期同期が終了するまで待ちます。 SAP SuccessFactors から Windows Server AD または Microsoft Entra ID に同期する場合、ディレクトリへの最初の同期が完了した後、Microsoft Entra は、Microsoft Entra 管理センターの SAP SuccessFactors アプリケーションの [プロビジョニング] タブで監査概要レポートを更新します。
Windows Server AD にプロビジョニングする場合、Windows Server AD で作成された新しいユーザーまたは Windows Server AD で更新されたユーザーが Windows Server AD から Microsoft Entra ID に同期されるまで待ちます。 Windows Server AD のユーザーが Microsoft Entra ID に変更を加えるまで待ち、ユーザーの Microsoft Entra ID 表現に Windows Server AD のユーザーとその属性の完全なセットが含まれるようにします。

Microsoft Entra クラウド同期を使用している場合、クラウド同期を表すサービスプリンシパルの同期ジョブを取得することで、同期状態の steadyStateLastAchievedTime を監視できます。サービスプリンシパル ID がない場合、「同期スキーマを表示する」を参照してください。
ユーザーが Microsoft Entra ID にプロビジョニングされていたことを確認します。 この時点で、ユーザーは Microsoft Entra ID に存在し、ターゲットアプリケーションで必要な属性を持っている必要があります。たとえば、ユーザーに givenname、surname、employeeID 属性が必要な場合があります。特定の属性を持つユーザーの数、または属性が不足しているユーザーの数を表示するには、次のスクリプトのような PowerShell コマンドを使用できます。
```
$u = get-mguser -all -property id,displayname,userprincipalname,usertype,givenname,surname,employeeid
$u2 = $u | where-object {$_.usertype -ne 'Guest' -and $_.employeeid -ne $null}
$u2c = $u2.Count
write-output "member users with employeeID attribute: $u2c"
$u3 = $u| Where-Object {$_.UserType -ne 'Guest' -and ($_.EmployeeId -eq $null -or $_.GivenName -eq $null -or $_.Surname -eq $null)}
$u3c = $u3.Count
write-output "member users missing employeeID, givenname or surname attributes: $u3c"
```
Microsoft Entra ID に予期しない、関連付けのないアカウントがないことを確認します。 通常、Microsoft Entra ID の一部のユーザーは、レコードソースの権限のあるシステムの worker に対応していません。これには、緊急管理アクセス用の非常用アカウント、IT ベンダーのアカウント、ビジネスゲストが含まれます。

ただし、現在の worker アカウントに似ているが、worker レコードと同期されなかった Microsoft Entra の孤立アカウントである場合もあります。孤立アカウントは、人事システムに参加しなくなった元従業員から発生する可能性があります。また、一致するエラーから発生する可能性もあります。または、名前を変更したユーザーや再雇用されたユーザーなど、データ品質の問題から発生する可能性があります。
Microsoft Entra へのレコードフローのアップストリームシステムで、結合、更新、および脱退アクティビティを正しくテストします。 詳細については、「テストを計画する」をご覧ください。

ユーザーが Microsoft Entra ID に存在するようになったので、次のセクションでは、ターゲットアプリケーションにユーザーをプロビジョニングします。

SAP Cloud Identity Services へのユーザーのプロビジョニング

このセクションの手順では、Microsoft Entra ID から SAP Cloud Identity Services へのプロビジョニングを構成します。既定では、SAP Cloud Identity Services に対してユーザーのプロビジョニングとプロビジョニング解除を自動的に実行できるように Microsoft Entra ID をセットアップします。その後、これらのユーザーは SAP Cloud Identity Services に対して認証を行い、SAP Cloud Identity Services と統合されている他の SAP ワークロードにアクセスできます。 SAP Cloud Identity Services では、そのローカル ID ディレクトリから他の SAP アプリケーションへ、ターゲットシステムとしてのプロビジョニングがサポートされています。

または、Microsoft Entra ID から読み取るように SAP Cloud Identity Services を構成することもできます。 SAP Cloud Identity Services を使用して Microsoft Entra ID からユーザーと必要に応じてグループを読み取る場合、SAP Cloud Identity Services の構成方法に関する SAP ガイダンスに従ってください。その後、次のセクションに進みます。

SAP Cloud Identity Services を使用していない場合は、次のセクションに進んでください。

SAP Cloud Identity Services テナントと SAP Cloud Identity Services での管理者アクセス許可を持つユーザーアカウントがあることを確認します。
プロビジョニング用に SAP Cloud Identity Services を設定します。 SAP Cloud Identity Services 管理コンソールにサインインし、「プロビジョニング用に SAP Cloud Identity Services を設定する」セクションの手順に従います。
ギャラリーから SAP Cloud Identity Services を追加し、SAP Cloud Identity Services への自動ユーザープロビジョニングを構成します。 「ギャラリーから SAP Cloud Identity Services を追加する」と「SAP Cloud Identity Services に対する自動ユーザープロビジョニングの構成」のセクションの手順に従います。
Microsoft Entra ID から SAP Cloud Identity Services にテストユーザーをプロビジョニングします。 「Microsoft Entra ID から SAP Cloud Identity Services に新しいテストユーザーをプロビジョニングする」セクションの手順に従って、プロビジョニング統合の準備ができていることを確認します。
Microsoft Entra と SAP Cloud Identity Services の両方の既存のユーザーを関連付けることができることを確認します。 Microsoft Entra ID のユーザーと SAP Cloud Identity Services に既に存在するユーザーを比較するには、次のセクションの手順に従います:
- 既存の SAP Cloud Identity Services ユーザーが必要な合致属性を持っていることを確認する
- 既存の Microsoft Entra ユーザーが必要な属性を持っていることを確認する
Microsoft Entra ID で SAP Cloud Identity Services の既存のユーザーをアプリケーションに割り当てます。 「Microsoft Entra ID で SAP Cloud Identity Services アプリケーションにユーザーを割り当てる」のセクションの手順に従います。これらの手順では、次の操作を行う必要があります:
- プロビジョニングが検疫されないように、プロビジョニングの問題に対処します。
- SAP Cloud Identity Services 内に存在し、Microsoft Entra ID 内のアプリケーションにまだ割り当てられていないユーザーを確認します。
- 残りのユーザーを割り当てます。
- 初期同期を監視します。
Microsoft Entra ID から SAP Cloud Identity Services への同期を待ちます。 アプリケーションに割り当てられたすべてのユーザーがプロビジョニングされるまで待ちます。初回サイクルには、20 分から数時間かかります。タイミングは、Microsoft Entra ディレクトリのサイズと、プロビジョニングの対象となるユーザー数によって異なります。 SAP Cloud Identity Services を表すサービスプリンシパルの同期ジョブを取得することで、同期状態の steadyStateLastAchievedTime プロパティを監視できます。
プロビジョニングエラーがないか確認します。 Microsoft Entra 管理センターまたは Graph API 経由でプロビジョニングログを確認します。ログを状態 [失敗] でフィルター処理します。

エラーコードでエラーが発生した場合、このコード DuplicateTargetEntries はプロビジョニング照合ルールのあいまいさを示します。各 Microsoft Entra ユーザーが 1 人のアプリケーションユーザーと一致するようにするには、Microsoft Entra ユーザーまたは照合に使用されるマッピングを更新する必要があります。次に、ログをアクション [作成] と状態 [スキップ済み] でフィルター処理します。

ユーザーが SkipReason* のコードNotEffectivelyEntitledでスキップされた場合、このログイベントは、ユーザーアカウントの状態が無効であるため、Microsoft Entra ID のユーザーアカウントが一致しなかったことを示している可能性があります。
SAP Cloud Identity Services のユーザーと Microsoft Entra ID のユーザーを比較します。 「既存の SAP Cloud Identity Services ユーザーが必要な合致属性を持っていることを確認する」セクションの手順を繰り返して、SAP Cloud Identity Services からユーザーを再エクスポートします。その後、エクスポートされたユーザーが SAP アプリケーションに必要なプロパティを持っていることを確認します。 PowerShell where-object コマンドを使用すると、{$_.employeeId -eq $null} などのフィルターによって、ユーザーの一覧を属性が不足しているユーザーだけにフィルター処理できます。
Microsoft Entra から SAP Cloud Identity Services へのフェデレーション SSO を構成します。 SAP Cloud Identity Services の SAML ベースの SSO を有効にします。「SAP Cloud Identity Services のシングルサインオンチュートリアル」に記載されている手順に従います。
アプリケーション Web エンドポイントを適切な条件付きアクセスポリシーのスコープに含めます。 同じガバナンス要件の対象となる別のアプリケーション用に作成された既存の条件付きアクセスポリシーがある可能性があります。その後、多数のポリシーを使用しないように、このアプリケーションにも適用するようにポリシーを更新できます。

更新の完了後、期待どおりのポリシーが適用されていることを確認します。ユーザーに適用されるポリシーは、条件付きアクセス What If ツールで確認できます。
テストユーザーが SAP アプリケーションに接続できることを検証します。 Microsoft マイアプリを使用して、アプリケーションの SSO をテストできます。テストユーザーが SAP Cloud Identity Services アプリケーションに割り当てられ、Microsoft Entra ID から SAP Cloud Identity Services にプロビジョニングされていることを確認します。その後、そのユーザーとして Microsoft Entra にサインインし、myapps.microsoft.com に移動します。

マイアプリで [SAP Cloud Identity Services] タイルをクリックすると、サービスプロバイダー (SP) モードで構成されている場合は、サインインフローを開始するためのアプリケーションサインインページにリダイレクトされます。 ID プロバイダー (IDP) モードで構成されている場合、SSO を設定した SAP Cloud Identity Services に自動的にサインインします。

SAP ECC にユーザーをプロビジョニングする

Microsoft Entra ID にユーザーが作成されたので、オンプレミスの SAP にユーザーをプロビジョニングできます。

SAP ECC を使用していない場合は、次のセクションに進みます。

プロビジョニングを構成します。 「NetWeaver AS ABAP 7.0 以降を使用して、SAP ECC にユーザーをプロビジョニングするように Microsoft Entra ID を構成する」の指示に従います。
Microsoft Entra ID から SAP ECC への同期を待ちます。 SAP ECC アプリケーションに割り当てられたすべてのユーザーがプロビジョニングされるまで待ちます。初回サイクルには、20 分から数時間かかります。タイミングは、Microsoft Entra ディレクトリのサイズと、プロビジョニングの対象となるユーザー数によって異なります。サービスプリンシパルの同期ジョブを取得することで、同期状態の steadyStateLastAchievedTime プロパティを監視できます。
プロビジョニングエラーがないか確認します。 Microsoft Entra 管理センターまたは Graph API 経由でプロビジョニングログを確認します。ログを状態 [失敗] でフィルター処理します。

エラーコード DuplicateTargetEntries でエラーが発生した場合、このログイベントは、プロビジョニングの一致ルールのあいまいさを示します。各 Microsoft Entra ユーザーが 1 人のアプリケーションユーザーと一致するように、Microsoft Entra ユーザーまたは照合に使用されるマッピングを更新する必要があります。次に、ログをアクション [作成] と状態 [スキップ済み] でフィルター処理します。

ユーザーが NotEffectivelyEntitled の SkipReason コードでスキップされた場合、このコードは、ユーザーアカウントの状態が無効であるため、Microsoft Entra ID のユーザーアカウントが一致しなかったことを示している可能性があります。
SAP ECC のユーザーと Microsoft Entra ID のユーザーを比較します。 SAP ECC にプロビジョニングするためのプロビジョニングエージェントをホストしている Windows Server で、Microsoft ECMA2Host Windows サービスを再起動します。サービスが再起動すると、SAP ECC からユーザーの完全なインポートが実行されます。
Microsoft Entra から SAP へのフェデレーション SSO を構成します。 SAP アプリケーションに対して SAML ベースの SSO を有効にします。 SAP NetWeaver を使用している場合、『SAP NetWeaver と SSO のチュートリアル』に記載されている手順に従います。
アプリケーション Web エンドポイントを適切な条件付きアクセスポリシーのスコープに含めます。 同じガバナンス要件の対象となる別のアプリケーション用に作成された既存の条件付きアクセスポリシーがある可能性があります。その後、多数のポリシーを使用しないように、このアプリケーションにも適用するようにポリシーを更新できます。

更新の完了後、期待どおりのポリシーが適用されていることを確認します。ユーザーに適用されるポリシーは、条件付きアクセス What If ツールで確認できます。
テストユーザーをプロビジョニングして SAP NetWeaver にサインインできることを検証します。 「SSO のテスト」セクションの手順に従って、条件付きアクセスが構成された後にユーザーがサインインできることを確認します。

SuccessFactors とその他のアプリケーションへのプロビジョニングを構成する

Microsoft Entra ID から SAP SuccessFactors Employee Central に特定の属性 (仕事用メールなど) が書き込まれるように Microsoft Entra を構成できます。詳細については、Microsoft Entra ID での SAP SuccessFactors の書き戻しの構成に関する記事をご覧ください。

Microsoft Entra は、OpenID Connect、SAML、SCIM、SQL、LDAP、SOAP、REST などの標準を使用するアプリケーションなど、他の多くのアプリケーションにもプロビジョニングできます。詳細については、「すべてのアプリと Microsoft Entra ID との統合」を参照してください。

Microsoft Entra で必要なアプリケーションアクセス権をユーザーに割り当てる

構成しているテナントが、SAP アプリケーションアクセス専用に構成された完全に分離されたテナントでない限り、テナント内のすべてのユーザーが SAP アプリケーションにアクセスすることの必要性はほとんどありません。テナント内の SAP アプリケーションは、アプリケーションへのアプリケーションロールの割り当てを持つユーザーのみがアプリケーションにプロビジョニングされ、Microsoft Entra ID からそのアプリケーションにサインインできるように構成されます。

アプリケーションに割り当てられているユーザーが Microsoft Entra ID で更新されると、それらの変更はそのアプリケーションに自動的にプロビジョニングされます。

Azure AD Identity Governance がある場合は、Microsoft Entra ID で SAP Cloud Identity Services または SAP ECC に対するアプリケーションロールの割り当ての変更を自動化できます。自動化を使用すると、ユーザーが組織に参加したり、ロールを離れたり変更したりするときに、割り当てを追加または削除できます。

既存の割り当てを確認します。 必要に応じて、アプリケーションロールの割り当ての 1 回限りのアクセスレビューを実行します。このレビューが終了すると、アクセスレビューによって、不要になった割り当てが削除されます。
アプリケーションロールの割り当てを最新の状態に保つようにプロセスを構成します。 Microsoft Entra エンタイトルメント管理を使用している場合、「PowerShell を使用して 1 つのロールを持つアプリケーションのエンタイトルメント管理でアクセスパッケージを作成する」を参照し、SAP クラウド ID サービスまたは SAP ECC を表すアプリケーションへの割り当てを構成します。

そのアクセスパッケージでは、ユーザーがアクセスを要求したときにアクセス権を割り当てるためのポリシーを設定できます。割り当ては、管理者が行うか、ルールに基づいて自動的に行うか、ライフサイクルワークフローを通じて生成できます。

Azure AD Identity Governance がない場合は、Microsoft Entra 管理センターで各ユーザーをアプリケーションに割り当てることができます。 PowerShell コマンドレット New-MgServicePrincipalAppRoleAssignedTo を使用して、個々のユーザーをアプリケーションに割り当てることができます。

新しく作成された Microsoft Entra ユーザーまたは Windows Server AD ユーザーに資格情報を配布する

この時点で、すべてのユーザーが Microsoft Entra ID に存在し、関連する SAP アプリケーションにプロビジョニングされます。このプロセス中に、Windows Server AD または Microsoft Entra ID に存在したことのない worker に対して作成されたすべてのユーザーには、新しい資格情報が必要です。

Microsoft Entra インバウンドプロビジョニングで Windows Server AD でユーザーが作成されている場合、新しく作成されたユーザーに対して Windows Server AD の初期資格情報を配布します。 Get-MgAuditLogProvisioning コマンドを使用して、Windows Server AD と Microsoft Entra の対話のイベントの一覧を取得できます。

ドメインに参加しているコンピューターで Set-ADAccountPassword コマンドを -Reset パラメーターと共に使用して、ユーザーの新しい Windows Server AD パスワードを設定できます。次に、Set-ADUser コマンドを -ChangePasswordAtLogon パラメーターを使用して、ユーザーが次のサインイン時に新しいパスワードを選択するように要求します。
Microsoft Entra インバウンドプロビジョニングで Microsoft Entra ID でユーザーが作成されている場合、新しく作成されたユーザーに対して Microsoft Entra ID の初期資格情報を配布します。 Get-MgAuditLogDirectoryAudit コマンドと Get-MgAuditLogDirectoryAudit -Filter "category eq 'UserManagement' and activityDisplayName eq 'Add user' and result eq 'success' and activityDateTime+ge+2024-05-01" -all などのパラメーターを共に使用して、新しく作成されたユーザーの一覧を取得できます。

ユーザーに対して一時アクセスパスを生成するには、New-MgUserAuthenticationTemporaryAccessPassMethod と Get-MgUserAuthenticationTemporaryAccessPassMethod コマンドを使用できます。これについては「一時アクセスパスを作成する」で扱われています。
ユーザーが MFA に登録されていることを確認します。 「MFA に登録されているユーザーに関する PowerShell のレポート」セクションにある PowerShell コマンドを実行して、MFA に登録されていないユーザーを特定できます。
一時的なポリシーの除外を必要とするユーザーがいる場合は、定期的なアクセスレビューを作成します。 場合によっては、すべての承認済みユーザーに対して条件付きアクセスポリシーをすぐに適用できないことがあります。たとえば、一部のユーザーは、適切な登録済みデバイスを持っていない場合があります。条件付きアクセスポリシーから 1 人以上のユーザーを除外し、そのユーザーにアクセスを許可する必要がある場合は、条件付きアクセスポリシーから除外されるユーザーのグループに対してアクセスレビューを構成します。

ID フローを監視する

アプリケーションでインバウンドプロビジョニングとアウトバウンドプロビジョニングが構成されたので、Microsoft Entra の自動化を使用して、権限のあるレコードシステムからターゲットアプリケーションへの継続的なプロビジョニングを監視できます。

インバウンドプロビジョニングの監視

プロビジョニングサービスによって実行されたアクティビティは、Microsoft Entra のプロビジョニングログに記録されます。プロビジョニングログには、Microsoft Entra 管理センターでアクセスできます。プロビジョニングデータは、ユーザー名か、ソースシステムまたはターゲットシステムの識別子に基づいて検索できます。詳細については、「プロビジョニングログ」を参照してください。

Windows Server AD での変更の監視

「Windows Server 監査ポリシーの推奨事項」で説明されているように、"ユーザーアカウント管理" 成功監査イベントがすべてのドメインコントローラーで有効になっており、分析のために収集されていることを確認します。

アプリケーションロールの割り当てを監視する

Azure Monitor に監査イベントを送信するように Microsoft Entra ID を構成した場合、Azure Monitor ブックを使用して、ユーザーがアクセスを受け取った方法に関する分析情報を取得できます。

Microsoft Entra エンタイトルメント管理を使用している場合、"アクセスパッケージアクティビティ" という名前のブックに特定のアクセスパッケージに関連する各イベントが表示されます。
アクセスパッケージの割り当てにより、アプリケーションのアプリケーションロールの割り当ての変更が作成されなかったかどうかを確認するには、"アプリケーションロールの割り当てアクティビティ" という名前のブックを選択します。エンタイトルメントアクティビティを省略することを選択した場合は、エンタイトルメント管理によって作成されたのではないアプリケーションロールに対する変更のみが表示されます。たとえば、別の管理者がアプリケーションロールにユーザーを直接割り当てた場合、行が表示されます。

アウトバウンドプロビジョニングの監視

Microsoft Entra と統合されたアプリケーションごとに、[同期の詳細] セクションを使用して進行状況を監視し、リンクをクリックしてプロビジョニングアクティビティレポートに移動できます。このレポートには、Microsoft Entra プロビジョニングサービスによってアプリケーションに対して実行されたすべてのアクションが記述されます。 Microsoft Graph API を使用してプロビジョニングプロジェクトを監視することもできます。

Microsoft Entra プロビジョニングログの読み方の詳細については、「自動ユーザーアカウントプロビジョニングについてのレポート」を参照してください。

SSO の監視

アプリケーションへの過去 30 日間のサインインは、Microsoft Entra 管理センターのサインインレポート、または Microsoft Graph で確認できます。また、Azure Monitor へのサインインログを送信し、サインインアクティビティを最大 2 年間アーカイブすることもできます。

Azure AD Identity Governance での割り当ての監視

Azure AD Identity Governance を使用している場合、Azure AD Identity Governance 機能を使用してアクセスする方法について報告できます。次に例を示します。

管理者またはカタログ所有者は、Microsoft Entra 管理センター、Microsoft Graph、PowerShell などを使用して、アクセスパッケージの割り当てを持つユーザーの一覧を取得できます。
また、監査ログを Azure Monitor に送信し、アクセスパッケージに対する変更の履歴を、Microsoft Entra 管理センターまたは PowerShell 経由で表示することもできます。

これらおよびその他の ID ガバナンスシナリオの詳細については、必要に応じて、エンタイトルメント管理ポリシーとアクセスを調整するために監視する方法をご覧ください。

次の方法で共有

SAP ソースアプリケーションとターゲットアプリケーションを使用したユーザープロビジョニングのために Microsoft Entra のデプロイを計画する

概要

SAP ソースとターゲットとの統合を計画する

アプリケーションオンボードのシーケンスと、アプリケーションと Microsoft Entra の統合方法を決定する