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

組織は、さまざまな 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 などのアプリケーションが組織内にある場合もあります。

1. SSO とプロビジョニングのために、アプリケーションを Microsoft Entra と統合するための優先順位を確立します。 通常、組織は最新のプロトコルをサポートするサービスとしてのソフトウェア (SaaS) アプリケーションとの統合を最初に行います。 SAP アプリケーションについては、SAP クラウド アプリケーションを持つ組織が、SAP Cloud Identity Services をミドルウェアとして使用して、SSO とプロビジョニングの統合から開始することをお勧めします。 ここでは、ユーザー プロビジョニングと SSO を Microsoft Entra に統合すると、複数の SAP アプリケーションにメリットがあります。

2. 各アプリケーションを 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 とプロビジョニングでサポートされる統合テクノロジを特定します。

3. 各アプリケーションが提供するロールとアクセス許可を収集します。 一部のアプリケーションには、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 によって定義されたロールがアプリケーションにインポートされ、アプリケーションのロールを使用してアプリケーション マニフェストが自動的に更新される場合があります。

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

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

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

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

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

   一部の組織では、従業員によるアクセス要求に 2 つの承認段階がある場合があります。 最初の段階は、ユーザーのマネージャーを要求することです。 2 番目の段階は、アプリケーションに保持されているデータを担当するリソース所有者の 1 人に要求することです。

2. アクセスを承認されたユーザーがアクセス権を得る期間と、そのアクセス権が取り消されるタイミングを決定します。 多くのアプリケーションでは、組織に所属しなくなるまで、ユーザーは無期限にアクセスを保持します。 状況によっては、アクセスが特定のプロジェクトまたはマイルストーンに関連付けられていて、プロジェクトが終了すると、アクセス権が自動的に削除されることがあります。 または、ポリシーを介してアプリケーションを使用しているユーザーが少ない場合は、そのポリシーを介したすべてのユーザーのアクセスを四半期ごとまたは年ごとにレビューするように構成し、定期的に監視されるようにすることができます。 これらのシナリオには、Microsoft Entra ID Governance が必要です。

3. 組織が既に組織のロール モデルを使ってアクセスを管理している場合は、その組織のロール モデルを Microsoft Entra ID に導入することを計画してください。 ユーザーのプロパティ (役職や部署など) に基づいてアクセス権を割り当てる組織ロール モデルが定義されている場合があります。 これらのプロセスにより、事前に決定されたプロジェクトの終了日がない場合でも、アクセスが不要になったときに最終的にユーザーがアクセス権を失うようにすることができます。

   既に組織ロールの定義がある場合は、Microsoft Entra ID Governance に組織ロールの定義を移行できます。

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

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

5. 各アプリケーションにアクセスするための適切な条件付きアクセス ポリシーを選択します。 アプリケーションを分析し、それらを同じユーザーに対して同じリソース要件があるアプリケーションのコレクションに整理することをお勧めします。

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

   条件付きアクセス ポリシーを定義する方法に関する考慮事項については、「条件付きアクセスのデプロイの計画」を参照してください。

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

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

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

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

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

   これらのテーマに関する包括的なガイドラインについては、クラウド人事デプロイ計画を参照してください。 サポートされるエンティティや処理の詳細、さまざまな人事シナリオに向けて統合をカスタマイズする方法については、「SAP SuccessFactors の統合に関するリファレンス」を参照してください。 また、他の ID に他の権限のあるソースがある場合があります。非常用アカウントや他の IT 管理者などの一部の ID は、Microsoft Entra ID が権限のあるソースである場合もあります。

2. 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 に同期されます。

3. 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」を参照してください。

4. ユーザーを 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 環境が適切に構成されていることを確認する必要があります。

1. Microsoft Entra ID と Microsoft Online Services 環境が、アプリケーションのコンプライアンス要件に対する準備ができていることを確認します。コンプライアンスは、Microsoft、クラウド サービス プロバイダーおよび組織の間での共同責任です。

2. 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 のいずれかです。

3. 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 を構成できます。

4. 許可されているユーザーのみが Microsoft Entra テナントの高い特権を持つ管理者ロールに含まれるようにします。 少なくとも ID ガバナンス管理者、ユーザー管理者、アプリケーション管理者、クラウド アプリケーション管理者、または特権ロール管理者である管理者は、ユーザーとそのアプリケーション ロールの割り当てを変更できます。 それらのロールのメンバーシップが最近まだレビューされていない場合は、少なくとも特権ロール管理者であるユーザーが、これらのディレクトリ ロールのアクセス レビューが開始されていることを確認する必要があります。

   また、Azure Monitor、Logic Apps、Microsoft Entra 構成の操作に必要なその他のリソースを保持するサブスクリプションの Azure ロールのユーザーが確認済みであることを確認する必要もあります。

5. テナントが適切に分離されていることを確認します。 組織がオンプレミスで Active Directory を使用していて、それらの AD ドメインが Microsoft Entra ID に接続されている場合は、クラウドでホストされるサービスに対する高い特権を使用する管理操作が、オンプレミス アカウントから分離されていることを確認する必要があります。 オンプレミスの侵害から Microsoft 365 のクラウド環境を保護するように構成していることを確認します。

6. セキュリティのベスト プラクティスに対して環境を評価します。 Microsoft Entra ID テナントをセキュリティで保護する方法を評価するには、「すべての分離アーキテクチャに関するベスト プラクティス」を確認します。

7. トークンの有効期間とアプリケーションのセッション設定を文書化します。 このチュートリアルの最後では、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 を使用していない場合は、次のセクションに進んでください。

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

2. 人事ソースに、これらの SAP クラウド アプリケーションに必要なスキーマを提供できる worker スキーマがあることを確認します。 アプリケーションに必要な各属性は、組織内のソースから生成される必要があります。 一部の属性には、定数または他の属性から変換される値が含まれる場合があります。 その他の値は、ユーザーのメール アドレスなど、Microsoft オンライン サービスによって割り当てられる場合があります。 ユーザーの名前、部門、その他の組織のプロパティなどの他の属性は、通常、権限のある人事レコード システムに由来します。

   先に進む前に、Microsoft Entra や別の Microsoft Online Service で生成されていない必須の各属性を、ソースから入手できるプロパティ (SuccessFactors など) に追跡できることを確認します。 ソースに必要なスキーマがない場合、またはこれらの属性がアプリケーションへのアクセス権を付与される 1 つ以上の ID に設定されていない場合、または Microsoft Entra が読み取りを使用できない場合は、プロビジョニングを有効にする前に、これらのスキーマ要件に対処する必要があります。

3. 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 に対して既に存在するユーザーを特定し、重複するユーザーが作成されないようにすることができます。

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

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

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

1. プロビジョニングに必要な BAPI が公開されていることを確認します。 ユーザーの作成、更新、削除に必要な API を SAP ECC NetWeaver 7.51 で公開します。 Deploying SAP NetWeaver AS ABAP 7.pdf という名前の Connectors for Microsoft Identity Manager 2016 ファイルでは、必要な API を公開する方法について説明します。

2. 既存の 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 を使用する必要がある場合があります。

3. 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 を介してアプリケーションに流れる方法のパスを文書化します。

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

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

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

1. 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 に登録してより強力な認証を行うことをお勧めします。

2. 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 にユーザーを作成します。 一時アクセス パス ポリシーを有効にして、新しいユーザーの一時的なアクセス パスを生成できるようにします。

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

   認証、場所、デバイス、使用条件に必要な条件を含む適切なポリシーが既にない場合は、条件付きアクセスのデプロイにポリシーを追加します。

4. 新しい worker に対して一時アクセス パスを発行する準備をします。 Azure AD Identity Governance を利用していて、Microsoft Entra ID へのインバウンド プロビジョニングを構成している場合は、新しい worker に対して一時アクセス パスを発行するようにライフサイクル ワークフローを構成することを計画します。

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 を使用しない場合は、次のセクションに進んでください。

1. 必要に応じて、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 など) を作成します。

2. 既存の 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 でそれらのユーザーを編集し、不足している属性を追加する必要があります。

3. 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 クラウド同期マッピングを構成します。 ライフサイクル ワークフローに必要な属性を同期していることを確認します。

4. 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 がない場合、「同期スキーマを表示する」を参照してください。

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

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

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

1. Microsoft Entra スキーマの拡張機能を保持するアプリケーションを作成します。 Windows Server AD から同期されていないテナントの場合、スキーマの拡張機能は新しいアプリケーションの一部である必要があります。 まだ作成していない場合は、スキーマの拡張機能を表すアプリケーションを作成します。 このアプリケーションに、ユーザーは割り当てられません。

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

   たとえば、一部の組織では、この目的のために新しい属性を持つよう Microsoft Entra ID ユーザー スキーマを拡張しています。 この目的で属性をまだ作成していない場合、次の手順でそれを属性として含めます。

3. 新しい属性のための Microsoft Entra ID ユーザー スキーマを拡張します。 Microsoft Entra ID ユーザー スキーマにまだ含まれていない SAP アプリケーションで必要な属性ごとにディレクトリ スキーマの拡張機能を作成します。 これらの属性により、Microsoft Entra はユーザーに関するより多くのデータを保存することができます。 拡張属性を作成することで、スキーマを拡張できます。

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

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

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

1. 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 に取り込みます。

1. 必要に応じて、使用条件のドキュメントをアップロードしてください。 ユーザーがアプリケーションにアクセスする前に使用条件に同意する必要がある場合は、条件付きアクセス ポリシーに含めることができるように、使用条件ドキュメントを作成してアップロードします。

2. 必要に応じて、カタログを作成します。 既定では、管理者が最初に Microsoft Entra エンタイトルメント管理を操作すると、既定のカタログが自動的に作成されます。 ただし、管理対象アプリケーションのアクセス パッケージは、指定されたカタログに含まれている必要があります。 Microsoft Entra 管理センターでカタログを作成するには、「カタログを作成する」セクションの手順に従います。

   PowerShell を使用してカタログを作成するには、「Microsoft Entra ID に対して認証する」と「カタログを作成する」のセクションの手順に従います。

3. 就職者ワークフローを作成します。 Microsoft Entra ID へのインバウンド プロビジョニングを構成している場合、新しい worker に対して一時アクセス パスを発行するタスクを含むライフサイクル ワークフローの就職者ワークフローを構成します。

4. サインインをブロックする退職者ワークフローを作成します。Microsoft Entra ライフサイクル ワークフローで、ユーザーのサインインをブロックするタスクを含む退職者ワークフローを構成します。 このワークフローは、オンデマンドで実行できます。 スケジュールされた退職日を過ぎると worker のサインインがブロックされるようにレコードのソースからのインバウンド プロビジョニングを構成しなかった場合、それらの worker のスケジュールされた退職日に対して実行する退職者ワークフローを構成します。

5. ユーザー アカウントを削除する退職者ワークフローを作成します。 必要に応じて、ユーザーを削除するタスクを含む退職者ワークフローを構成します。 このワークフローは、worker のスケジュールされた退職日から 30 日や 90 日後など、ある期間実行するようにスケジュールします。

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

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

1. サービス アカウントを使用してレコードのシステムを構成し、Microsoft Entra ID に適切なアクセス許可を付与します。 SAP SuccessFactors を使用している場合、「統合のための SuccessFactors の構成」セクションの手順に従います。

2. レコードのシステムから 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 ユーザー属性に対して [この属性を使用してオブジェクトを照合する] を使用してマッピングを構成していることを確認します。 また、作業者の入社日と退社日に必要な属性と、人事ソースから生成された宛先アプリケーションで必要なすべての属性のマッピングも構成します。

3. レコードのシステムからの初期インバウンド プロビジョニングを実行します。 SAP SuccessFactors を使用しており、Windows Server AD と Microsoft Entra ID にユーザーをプロビジョニングする場合、「プロビジョニングの有効化と起動」のセクションの手順に従います。 SAP SuccessFactors を使用しており、Windows Server AD にプロビジョニングしない場合、「プロビジョニングの有効化と起動」のセクションの手順に従います。

4. レコードのシステムからの初期同期が終了するまで待ちます。 SAP SuccessFactors から Windows Server AD または Microsoft Entra ID に同期する場合、ディレクトリへの最初の同期が完了した後、Microsoft Entra は、Microsoft Entra 管理センターの SAP SuccessFactors アプリケーションの [プロビジョニング] タブで監査概要レポート を更新します。

   

5. 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 がない場合、「同期スキーマを表示する」を参照してください。

6. ユーザーが 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"
   

7. Microsoft Entra ID に予期しない、関連付けのないアカウントがないことを確認します。 通常、Microsoft Entra ID の一部のユーザーは、レコード ソースの権限のあるシステムの worker に対応していません。 これには、緊急管理アクセス用の非常用アカウント、IT ベンダーのアカウント、ビジネス ゲストが含まれます。

   ただし、現在の worker アカウントに似ているが、worker レコードと同期されなかった 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 を使用していない場合は、次のセクションに進んでください。

1. 管理者アクセス許可を持つ SAP Cloud Identity Services のユーザー アカウントで SAP Cloud Identity Services テナントがあることを確認します。

2. プロビジョニング用に SAP Cloud Identity Services を設定します。 SAP Cloud Identity Services 管理コンソールにサインインし、「プロビジョニング用に SAP Cloud Identity Services を設定する」セクションの手順に従います。

3. ギャラリーから SAP Cloud Identity Services を追加し、SAP Cloud Identity Services への自動ユーザー プロビジョニングを構成します。 「ギャラリーから SAP Cloud Identity Services を追加する」と「SAP Cloud Identity Services に対する自動ユーザー プロビジョニングの構成」のセクションの手順に従います。

4. Microsoft Entra ID から SAP Cloud Identity Services にテスト ユーザーをプロビジョニングします。 「Microsoft Entra ID から SAP Cloud Identity Services に新しいテスト ユーザーをプロビジョニングする」セクションの手順に従って、プロビジョニング統合の準備ができていることを確認します。

5. Microsoft Entra と SAP Cloud Identity Services の両方の既存のユーザーを関連付けることができることを確認します。 Microsoft Entra ID のユーザーと SAP Cloud Identity Services に既に存在するユーザーを比較するには、次のセクションの手順に従います:

   • 既存の SAP Cloud Identity Services ユーザーが必要な合致属性を持っていることを確認する
   • 既存の Microsoft Entra ユーザーが必要な属性を持っていることを確認する

6. Microsoft Entra ID で SAP Cloud Identity Services の既存のユーザーをアプリケーションに割り当てます。 「Microsoft Entra ID で SAP Cloud Identity Services アプリケーションにユーザーを割り当てる」のセクションの手順に従います。 これらの手順では、次の操作を行う必要があります:

   • プロビジョニングが検疫されないように、プロビジョニングの問題に対処します。
   • SAP Cloud Identity Services 内に存在し、Microsoft Entra ID 内のアプリケーションにまだ割り当てられていないユーザーを確認します。
   • 残りのユーザーを割り当てます。
   • 初期同期を監視します。

7. Microsoft Entra ID から SAP Cloud Identity Services への同期を待ちます。 アプリケーションに割り当てられたすべてのユーザーがプロビジョニングされるまで待ちます。 初回サイクルには、20 分から数時間かかります。 タイミングは、Microsoft Entra ディレクトリのサイズと、プロビジョニングの対象となるユーザー数によって異なります。 SAP Cloud Identity Services を表すサービス プリンシパルの同期ジョブを取得することで、同期状態の steadyStateLastAchievedTime プロパティを監視できます。

8. プロビジョニング エラーがないか確認します。 Microsoft Entra 管理センターまたは Graph API 経由でプロビジョニング ログを確認します。 ログを状態 [失敗] でフィルター処理します。

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

   ユーザーが SkipReason* のコードNotEffectivelyEntitledでスキップされた場合、このログ イベントは、ユーザー アカウントの状態が無効であるため、Microsoft Entra ID のユーザー アカウントが一致しなかったことを示している可能性があります。

9. SAP Cloud Identity Services のユーザーと Microsoft Entra ID のユーザーを比較します。 「既存の SAP Cloud Identity Services ユーザーが必要な合致属性を持っていることを確認する」セクションの手順を繰り返して、SAP Cloud Identity Services からユーザーを再エクスポートします。 その後、エクスポートされたユーザーが SAP アプリケーションに必要なプロパティを持っていることを確認します。 PowerShell where-object コマンドを使用すると、{$_.employeeId -eq $null} などのフィルターによって、ユーザーの一覧を属性が不足しているユーザーだけにフィルター処理できます。

10. Microsoft Entra から SAP Cloud Identity Services へのフェデレーション SSO を構成します。 SAP Cloud Identity Services の SAML ベースの SSO を有効にします。 「SAP Cloud Identity Services のシングル サインオン チュートリアル」に記載されている手順に従います。

11. アプリケーション Web エンドポイントを適切な条件付きアクセス ポリシーのスコープに含めます。 同じガバナンス要件の対象となる別のアプリケーション用に作成された既存の条件付きアクセス ポリシーがある可能性があります。 その後、多数のポリシーを使用しないように、このアプリケーションにも適用するようにポリシーを更新できます。

    更新の完了後、期待どおりのポリシーが適用されていることを確認します。 ユーザーに適用されるポリシーは、条件付きアクセス What If ツールで確認できます。

12. テスト ユーザーが 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 を使用していない場合は、次のセクションに進みます。

1. プロビジョニングを構成します。 「NetWeaver AS ABAP 7.0 以降を使用して、SAP ECC にユーザーをプロビジョニングするように Microsoft Entra ID を構成する」の指示に従います。

2. Microsoft Entra ID から SAP ECC への同期を待ちます。 SAP ECC アプリケーションに割り当てられたすべてのユーザーがプロビジョニングされるまで待ちます。 初回サイクルには、20 分から数時間かかります。 タイミングは、Microsoft Entra ディレクトリのサイズと、プロビジョニングの対象となるユーザー数によって異なります。 サービス プリンシパルの同期ジョブを取得することで、同期状態の steadyStateLastAchievedTime プロパティを監視できます。

3. プロビジョニング エラーがないか確認します。 Microsoft Entra 管理センターまたは Graph API 経由でプロビジョニング ログを確認します。 ログを状態 [失敗] でフィルター処理します。

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

   ユーザーが NotEffectivelyEntitled の SkipReason コードでスキップされた場合、このコードは、ユーザー アカウントの状態が無効であるため、Microsoft Entra ID のユーザー アカウントが一致しなかったことを示している可能性があります。

4. SAP ECC のユーザーと Microsoft Entra ID のユーザーを比較します。 SAP ECC にプロビジョニングするためのプロビジョニング エージェントをホストしている Windows Server で、Microsoft ECMA2Host Windows サービスを再起動します。 サービスが再起動すると、SAP ECC からユーザーの完全なインポートが実行されます。

5. Microsoft Entra から SAP へのフェデレーション SSO を構成します。 SAP アプリケーションに対して SAML ベースの SSO を有効にします。 SAP NetWeaver を使用している場合、『SAP NetWeaver と SSO のチュートリアル』に記載されている手順に従います。

6. アプリケーション Web エンドポイントを適切な条件付きアクセス ポリシーのスコープに含めます。 同じガバナンス要件の対象となる別のアプリケーション用に作成された既存の条件付きアクセス ポリシーがある可能性があります。 その後、多数のポリシーを使用しないように、このアプリケーションにも適用するようにポリシーを更新できます。

   更新の完了後、期待どおりのポリシーが適用されていることを確認します。 ユーザーに適用されるポリシーは、条件付きアクセス What If ツールで確認できます。

7. テスト ユーザーをプロビジョニングして 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. 既存の割り当てを確認します。 必要に応じて、アプリケーション ロールの割り当ての 1 回限りのアクセス レビューを実行します。 このレビューが終了すると、アクセス レビューによって、不要になった割り当てが削除されます。

2. アプリケーション ロールの割り当てを最新の状態に保つようにプロセスを構成します。 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 に対して作成されたすべてのユーザーには、新しい資格情報が必要です。

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

   ドメインに参加しているコンピューターで Set-ADAccountPassword コマンドを -Reset パラメーターと共に使用して、ユーザーの新しい Windows Server AD パスワードを設定できます。 次に、Set-ADUser コマンドを -ChangePasswordAtLogon パラメーターを使用して、ユーザーが次のサインイン時に新しいパスワードを選択するように要求します。

2. 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 コマンドを使用できます。これについては「一時アクセス パスを作成する」で扱われています。

3. ユーザーが MFA に登録されていることを確認します。 「MFA に登録されているユーザーに関する PowerShell のレポート」セクションにある PowerShell コマンドを実行して、MFA に登録されていないユーザーを特定できます。

4. 一時的なポリシーの除外を必要とするユーザーがいる場合は、定期的なアクセス レビューを作成します。 場合によっては、すべての承認済みユーザーに対して条件付きアクセス ポリシーをすぐに適用できないことがあります。 たとえば、一部のユーザーは、適切な登録済みデバイスを持っていない場合があります。 条件付きアクセス ポリシーから 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 ガバナンス シナリオの詳細については、必要に応じて、エンタイトルメント管理ポリシーとアクセスを調整するために監視する方法をご覧ください。

関連するコンテンツ

• 環境内のアプリケーションのアクセスを制御する
• 組織のロール モデルを Microsoft Entra ID Governance に移行してアクセスを管理する
• 環境内のアプリケーションへのアクセスを管理するための組織のポリシーを定義する
• Microsoft Entra ID を使用して SAP プラットフォームおよびアプリケーションへのアクセスをセキュリティで保護する
• SAP on Azure の組織の ID とガバナンスの基礎を探索する