Microsoft Entra ID での Microsoft Entra ID でのアプリケーションプロビジョニングのしくみ

[アーティクル]
10/25/2023

自動プロビジョニングとは、ユーザーがアクセスする必要のあるクラウドアプリケーションのユーザー ID とロールを作成することです。自動プロビジョニングには、ユーザー ID の作成に加えて、状態または役割が変化したときのユーザー ID のメンテナンスおよび削除が含まれます。デプロイを開始する前に、この記事を参照して Microsoft Entra プロビジョニングのしくみを学習し、構成に関する推奨事項を確認することができます。

Microsoft Entra プロビジョニングサービスでは、アプリケーションベンダーまたはオンプレミスプロビジョニングエージェントによって提供される System for Cross-Domain Identity Management (SCIM) 2.0 ユーザー管理 API エンドポイントに接続することによって、SaaS アプリや他のシステムにユーザーがプロビジョニングされます。 Microsoft Entra ID では、この SCIM エンドポイントを使って、プログラムによってユーザーが作成、更新、削除されます。一部のアプリケーションについては、ID に関連する他のオブジェクト (グループなど) をプロビジョニングサービスで作成、更新、削除することもできます。 Microsoft Entra ID とアプリケーションの間のプロビジョニングに使われるチャネルは、HTTPS TLS 1.2 暗号化を使って暗号化されます。

Microsoft Entra プロビジョニングサービス "図 1: Microsoft Entra プロビジョニングサービス"

出力方向のユーザープロビジョニングワークフロー "図 2: Microsoft Entra ID から主要 SaaS アプリケーションへの "出力方向" のユーザープロビジョニングワークフロー"

入力方向のユーザープロビジョニングワークフロー "図 3: 主要な人材管理 (HCM) アプリケーションから Microsoft Entra ID および Windows Server Active Directory への "入力方向" のユーザープロビジョニングワークフロー"

SCIM 2.0 を使用したプロビジョニング

Microsoft Entra プロビジョニングサービスでは、自動プロビジョニングに SCIM 2.0 プロトコルが使われます。このサービスは、アプリケーションの SCIM エンドポイントに接続され、SCIM ユーザーオブジェクトスキーマおよび REST API を使用してユーザーとグループのプロビジョニングとプロビジョニング解除を自動化します。 Microsoft Entra ギャラリーでは、ほとんどのアプリケーションに対して SCIM ベースのプロビジョニングコネクタが用意されています。開発者は、Microsoft Entra ID で SCIM 2.0 ユーザー管理 API を使って、プロビジョニングサービスに統合するアプリのためのエンドポイントを構築します。詳細については、SCIM エンドポイントの構築とプロビジョニングの構成に関するページを参照してください。また、オンプレミスプロビジョニングエージェントは、Microsoft Entra SCIM の操作を、LDAP、SQL、REST または SOAP、PowerShell、カスタム ECMA コネクタの呼び出し、またはパートナーによって構築されたコネクタとゲートウェイに変換します。

自動 Microsoft Entra プロビジョニングコネクタが現在ないアプリに対してこのコネクタを要求するには、Microsoft Entra アプリケーション要求に関するページを参照してください。

認可

Microsoft Entra ID をアプリケーションのユーザー管理 API に接続するには、資格情報が必要です。アプリケーションの自動ユーザープロビジョニングを構成している間に、有効な資格情報を入力する必要があります。ギャラリーアプリケーションの場合、アプリケーションの資格情報の種類と要件については、アプリのチュートリアルを参照してください。ギャラリー以外のアプリケーションの場合は、SCIM のドキュメントを参照して、資格情報の種類と要件を理解することができます。 Microsoft Entra 管理センターで、資格情報をテストできます (Microsoft Entra ID により、指定された資格情報を使用してアプリのプロビジョニングアプリへの接続が試行されます)。

属性のマッピング

サードパーティの SaaS アプリケーションでユーザープロビジョニングを有効にすると、Microsoft Entra 管理センターでは属性マッピングによってその属性値が管理されます。マッピングにより、ユーザーアカウントをプロビジョニングまたは更新するときに Microsoft Entra ID とターゲットアプリケーションの間でフローするユーザー属性が決定されます。

Microsoft Entra ユーザーオブジェクトと各 SaaS アプリのユーザーオブジェクトの間には、事前構成済みの一連の属性と属性マッピングが存在します。アプリによっては、ユーザーに加えてグループなど他の種類のオブジェクトを管理するものもあります。

プロビジョニングを設定するときは、どのユーザー (またはグループ) プロパティが Microsoft Entra ID からアプリケーションに提供されるかを定義する属性マッピングとワークフローを確認して構成することが重要です。 2 つのシステム間でユーザーまたはグループを一意に識別して照合するために使用される照合プロパティ (この属性を使用してオブジェクトを照合します) を確認して構成します。

既定の属性マッピングをビジネスのニーズに合わせてカスタマイズできます。そのため、既存の属性マッピングを変更、削除したり、新規の属性マッピングを作成したりすることができます。詳細については、SaaS アプリケーションに対するユーザープロビジョニング属性マッピングのカスタマイズに関するページを参照してください。

SaaS アプリケーションに対してプロビジョニングを構成するときに指定できる属性マッピングの種類の 1 つは、式マッピングです。これらのマッピングでは、ユーザーのデータを SaaS アプリケーションが許容可能な形式に変換することができる、スクリプトのような式を記述する必要があります。詳細については、属性マッピングの式の書き方に関するページを参照してください。

Scoping

割り当てベースのスコープ

Microsoft Entra ID から SaaS アプリケーションへの送信プロビジョニングでは、ユーザーまたはグループの割り当てに依存することが、プロビジョニングの対象となるユーザーを特定する最も一般的な方法です。ユーザー割り当てはシングルサインオンの有効化にも使用されるため、アクセスとプロビジョニングの両方を管理するのに同じ方法を使用できます。割り当てベースのスコープは、Workday や Successfactors などの受信プロビジョニングシナリオには適用されません。

グループ。 Microsoft Entra ID P1 または P2 ライセンスプランを利用すると、グループを使って SaaS アプリケーションにアクセスを割り当てることができます。プロビジョニングスコープが、割り当てられているユーザーおよびグループのみを同期するように設定されている場合、Microsoft Entra プロビジョニングサービスでは、ユーザーがアプリケーションに割り当てられているグループのメンバーであるかどうかに基づいて、ユーザーがプロビジョニングまたはプロビジョニング解除されます。アプリケーションでグループオブジェクトがサポートされていない場合、グループオブジェクト自体はプロビジョニングされません。アプリケーションに割り当てられているグループで、プロパティ "SecurityEnabled" が "True" に設定されていることを確認します。
動的グループ。 Microsoft Entra ユーザープロビジョニングサービスでは、動的グループのユーザーの読み取りとプロビジョニングを行うことができます。次の注意事項と推奨事項に留意してください。
- 動的グループは、Microsoft Entra ID から SaaS アプリケーションへのエンドツーエンドのプロビジョニングのパフォーマンスに影響を与えることがあります。
- SaaS アプリケーションで動的グループのユーザーをプロビジョニングまたはプロビジョニング解除する速度は、動的グループがメンバーシップの変更を評価する速さによって決まります。動的グループの処理状態を確認する方法については、メンバーシップルールの処理状態のチェックに関するページを参照してください。
- 動的グループのユーザーのメンバーシップが失われると、プロビジョニング解除イベントと見なされます。動的グループのルールを作成する場合は、このシナリオを検討してください。
入れ子になったグループ。 Microsoft Entra ユーザープロビジョニングサービスでは、入れ子になったグループのユーザーの読み取りやプロビジョニングを行うことはできません。このサービスでは、明示的に割り当てられたグループの直接のメンバーであるユーザーだけを読み取ってプロビジョニングすることができます。 "アプリケーションへのグループベースの割り当て" のこの制限は、シングルサインオンにも影響を与えます (「SaaS アプリケーションへのアクセスをグループで管理する」を参照)。代わりに、プロビジョニングする必要のあるユーザーを含むグループを明示的に割り当てるか、またはスコープ設定します。

属性ベースのスコープ

スコープフィルターを使用して、アプリケーションにプロビジョニングするユーザーを決める、属性ベースのルールを定義できます。この方法は、一般的に、HCM アプリケーションから Microsoft Entra ID および Active Directory への受信プロビジョニングに使われます。スコープフィルターは各 Microsoft Entra ユーザープロビジョニングコネクタの属性マッピングで設定されます。属性ベースのスコープフィルターの構成の詳細については、「スコープフィルターを使用した属性ベースのアプリケーションプロビジョニング」を参照してください。

B2B (ゲスト) ユーザー

Microsoft Entra ユーザープロビジョニングサービスを使って、Microsoft Entra ID の B2B (ゲスト) ユーザーを SaaS アプリケーションにプロビジョニングすることは可能です。ただし、B2B ユーザーが Microsoft Entra ID を使って SaaS アプリケーションにサインインするには、Microsoft Entra ID を Security Assertion Markup Language (SAML) ID プロバイダーとして使うように SaaS アプリケーションを手動で構成する必要があります。

B2B (ゲスト) ユーザー用に SaaS アプリを構成する場合は、こちらの一般的なガイドラインに従います。

ほとんどのアプリでは、ユーザーセットアップを手動で起動する必要があります。アプリでユーザーも手動で作成する必要があります。
Dropbox のように、自動セットアップをサポートしているアプリでは、アプリから個別の招待が作成されます。ユーザーは各招待に確実に応じる必要があります。
ゲストユーザーの壊れたユーザープロファイルディスク (UPD) の問題を緩和するには、常にユーザー属性のユーザー識別子を user.mail に設定します。

Note

B2B コラボレーションユーザーの userPrincipalName では、外部ユーザーのメールアドレス alias@theirdomain は "alias_theirdomain#EXT#@yourdomain" と表されます。 userPrincipalName 属性がソース属性として属性マッピングに含まれていて、B2B ユーザーがプロビジョニングされている場合、#EXT# とドメインは userPrincipalName から削除されるため、元の alias@theirdomain のみが照合またはプロビジョニングに使用されます。 #EXT# とドメインを含む完全なユーザープリンシパル名が存在する必要がある場合は、userPrincipalName をソース属性として originalUserPrincipalName に置き換えます。
userPrincipalName = alias@theirdomain
originalUserPrincipalName = alias_theirdomain#EXT#@yourdomain

プロビジョニングサイクル:初回と増分

Microsoft Entra ID がソースシステムである場合、プロビジョニングサービスでは、Microsoft Graph データの変更を追跡するためにデルタクエリを使って、ユーザーとグループを監視します。プロビジョニングサービスは、ソースシステムとターゲットシステムに対して初回サイクルを実行した後、増分サイクルを定期的に行います。

初回サイクル

プロビジョニングサービスが開始されたときの初回サイクルでは、次の処理が実行されます。

ソースシステムのすべてのユーザーとグループにクエリを実行し、属性マッピングで定義されているすべての属性を取得します。
返されたユーザーおよびグループを、構成済み割り当てまたは属性ベースのスコープフィルターを使用してフィルター処理します。
ユーザーが割り当て済み、またはプロビジョニング対象の場合、サービスはターゲットシステムに対してクエリを実行し、指定された照合属性を使用して、一致するユーザーがいないかどうかを確認します。例:ソースシステムの userPrincipal 名が一致属性であり、ターゲットシステムの userName にマップされる場合、プロビジョニングサービスは、ターゲットシステムにクエリを実行し、ソースシステムの userPrincipal 名の値と一致する userName がないかどうかを確認します。
一致するユーザーがターゲットシステムで見つからない場合、ソースシステムから返された属性を使用してユーザーが作成されます。ユーザーアカウントが作成されると、プロビジョニングサービスでは、その新しいユーザー用のターゲットシステムの ID が検出されてキャッシュされます。この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。
一致するユーザーが見つかった場合、そのユーザーは、ソースシステムによって提供された属性を使用して更新されます。ユーザーアカウントが照合されると、プロビジョニングサービスでは、その新しいユーザー用のターゲットシステムの ID が検出されてキャッシュされます。この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。
属性マッピングに「参照」属性が含まれている場合、サービスは、ターゲットシステムで追加の更新を実行して参照先オブジェクトを作成し、リンクします。たとえば、あるユーザーがターゲットシステムで "Manager" 属性を持ち、それがターゲットシステムで作成された別のユーザーにリンクされている場合があります。
初回サイクルの終了時に基準値を保持します。これは、以降の増分サイクルの始点になります。

ServiceNow、G Suite、Box など、アプリケーションの中には、ユーザーのプロビジョニングだけでなく、グループとそのメンバーのプロビジョニングをサポートしているものがあります。このような場合、グループのプロビジョニングがマッピングで有効になっていると、プロビジョニングサービスは、ユーザーとグループを同期したうえで、グループメンバーシップを同期します。

増分サイクル

初回サイクルの後、他のすべてのサイクルでは以下が行われます。

ソースシステムにクエリを実行し、前回の基準値が保存された後に更新されたユーザーおよびグループがないかどうかを確認します。
返されたユーザーおよびグループを、構成済み割り当てまたは属性ベースのスコープフィルターを使用してフィルター処理します。
ユーザーが割り当て済み、またはプロビジョニング対象の場合、サービスはターゲットシステムに対してクエリを実行し、指定された照合属性を使用して、一致するユーザーがいないかどうかを確認します。
一致するユーザーがターゲットシステムで見つからない場合、ソースシステムから返された属性を使用してユーザーが作成されます。ユーザーアカウントが作成されると、プロビジョニングサービスでは、その新しいユーザー用のターゲットシステムの ID が検出されてキャッシュされます。この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。
一致するユーザーが見つかった場合、そのユーザーは、ソースシステムによって提供された属性を使用して更新されます。照合されたのが新しく割り当てられたアカウントである場合、プロビジョニングサービスでは、その新しいユーザー用のターゲットシステムの ID が検出されてキャッシュされます。この ID は、そのユーザーに対する今後のすべての操作を実行するために使用されます。
属性マッピングに「参照」属性が含まれている場合、サービスは、ターゲットシステムで追加の更新を実行して参照先オブジェクトを作成し、リンクします。たとえば、あるユーザーがターゲットシステムで "Manager" 属性を持ち、それがターゲットシステムで作成された別のユーザーにリンクされている場合があります。
以前プロビジョニングの対象であったユーザーが対象から外れた場合 (割り当てられていない場合を含む)、このサービスでは、更新を通じてターゲットシステムでこのユーザーが無効化されます。
以前プロビジョニングの対象だったユーザーが、ソースシステムで無効にされた場合、または論理削除された場合、サービスは、更新によってターゲットシステムのユーザーを無効にします。
以前プロビジョニングの対象だったユーザーが、ソースシステムから物理的に削除された場合、サービスは、ターゲットシステムのユーザーを削除します。 Microsoft Entra ID では、論理削除されたユーザーは、削除されてから 30 日後に物理的に削除されます。
増分サイクルの終了時に新しい基準値を保持します。これは、以降の増分サイクルの始点になります。

Note

[マッピング] セクションの [対象オブジェクトのアクション] チェックボックスを使用して、 [作成] 、 [更新] 、または [削除] 操作を必要に応じて無効にできます。更新中にユーザーを無効にするロジックは、accountEnabled などのフィールドの属性マッピングでも制御されます。

プロビジョニングサービスでは、バックツーバック増分サイクルが、各アプリケーションに固有のチュートリアルで定義された間隔で無期限に実行され続けます。増分サイクルは、次のいずれかのイベントが発生するまで続行されます:

Microsoft Entra 管理センターまたは適切な Microsoft Graph API コマンドを使用してサービスが手動で停止された。
Microsoft Entra 管理センターの [プロビジョニングを再起動] オプション、または適切な Microsoft Graph API コマンドを使用して、新しい初回サイクルがトリガーされます。このアクションでは、保存されたウォーターマークがクリアされ、すべてのソースオブジェクトが再評価されます。また、アクションはソースオブジェクトとターゲットオブジェクト間のリンクを中断しません。リンクを解除するには、次の要求で同期ジョブの再起動を使用します:

POST https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/restart
Authorization: Bearer <token>
Content-type: application/json
{
   "criteria": {
       "resetScope": "Full"
   }
}

属性マッピングまたはスコープフィルターの変更によって、新しい初回サイクルがトリガーされた。また、この操作では、保存された基準値がクリアされ、すべてのソースオブジェクトが再評価されます。
高いエラー率によりプロビジョニングプロセスが検査に移行し (以下を参照)、そのまま 4 週間を超えて検査にとどまっている。この場合、サービスは自動的に無効になります。

エラーと再試行

ターゲットシステムでのエラーが原因で個々のユーザーの追加、更新、または削除がターゲットシステム上で行えない場合、その操作は次の同期サイクルで再試行されます。エラーは継続的に再試行され、再試行頻度は徐々に減らされます。エラーを解決するには、管理者がプロビジョニングログを確認し、根本原因を特定して、適切な対応を取る必要があります。たとえば、次のような一般的なエラーがあります。

ターゲットシステムで必要な属性がソースシステムのユーザーに設定されていない
ソースシステムのユーザーの属性値に対して、ターゲットシステムに一意の制約があり、同じ値が他のユーザーレコードに存在する

このようなエラーを解決するには、ソースシステムで影響を受けるユーザーの属性値を調整するか、競合が発生しないように属性マッピングを調整します。

検疫

ターゲットシステムに対する呼び出しのほとんどまたはすべてが、常にエラー (管理者の資格情報が無効である場合など) が原因で失敗する場合、プロビジョニングジョブは "検疫" 状態になります。この状態は、プロビジョニング概要レポート、または電子メール (電子メール通知が Microsoft Entra 管理センターで構成されている場合) で示されます。

検疫状態であると、増分サイクルの頻度は徐々に減少し、最終的には 1 日 1 回になります。

問題を引き起こしているすべてのエラーが修正されたら、プロビジョニングジョブは検疫から削除され、次の同期サイクルが開始されます。プロビジョニングジョブが検疫にとどまっている期間が 4 週間を超えると、そのプロビジョニングジョブは無効になります。検疫の状態の詳細については、こちらを参照してください。

プロビジョニングにかかる時間

プロビジョニングジョブで実行されているのが初期プロビジョニングサイクルか増分サイクルかによって、パフォーマンスが異なります。プロビジョニングにかかる時間、およびプロビジョニングサービスの状態を監視する方法について詳しくは、ユーザープロビジョニングの状態の確認に関するページをご覧ください。

ユーザーが正しくプロビジョニングされているかどうかを確認する方法

ユーザープロビジョニングサービスによって実行された操作はすべて、Microsoft Entra のプロビジョニングログ (プレビュー) に記録されます。このログには、ソースシステムとターゲットシステムに対して実行されたすべての読み取りおよび書き込み操作と、各操作の際に読み取られたり書き込まれたりしたユーザーデータが含まれます。 Microsoft Entra 管理センターでプロビジョニングログを確認する方法については、プロビジョニングレポートに関するガイドを参照してください。

Deprovisioning

Microsoft Entra プロビジョニングサービスでは、ユーザーアクセスが削除された場合に、アカウントをプロビジョニング解除することによってソースおよびターゲットシステムの同期が維持されます。

ユーザーの削除と無効化 (論理的な削除とも呼ばれます) の両方が、このプロビジョニングサービスによってサポートされています。無効化と削除の厳密な定義は、ターゲットアプリの実装によって異なりますが、一般に、無効化とはユーザーがサインインできないことを示します。削除とは、ユーザーがアプリケーションから完全に削除されたことを示します。 SCIM アプリケーションの場合、無効化は、ユーザーに対して active プロパティを false に設定する要求です。

ユーザーを無効にするようにアプリケーションを構成する

更新のチェックボックスが選択されていることを確認します。

ご利用のアプリケーション用の active のマッピングを確保します。アプリケーションギャラリーからのアプリケーションを使用している場合は、マッピングが若干異なることがあります。このケースでは、ギャラリーアプリケーションのデフォルトマッピングを使用します。

ユーザーを削除するようにアプリケーションを構成する

次のシナリオでは、無効化または削除がトリガーされます。

Microsoft Entra ID 内でユーザーを論理的に削除する (ごみ箱に入れられます、AccountEnabled プロパティが false に設定されます)。 Microsoft Entra ID でユーザーが削除されてから 30 日後に、テナントから完全に削除されます。この時点で、プロビジョニングサービスによって削除要求が送信されて、アプリケーション内のユーザーが完全に削除されます。 30 日間の期間中はいつでも、ユーザーを手動で完全に削除することができます。これにより、削除要求がアプリケーションに送信されます。
ユーザーを Microsoft Entra ID のごみ箱から完全に削除または除去する。
ユーザーをアプリから割り当て解除する。
ユーザーをスコープ内からスコープ外に移動する (スコープフィルターを通過しなくなります)。

既定では、Microsoft Entra プロビジョニングサービスにより、スコープ外になったユーザーが論理的に削除または無効化されます。この既定の動作をオーバーライドする場合は、スコープ外の削除をスキップするようにフラグを設定します。

4 つのイベントのいずれかが発生し、ターゲットアプリケーションで論理的な削除がサポートされていない場合は、プロビジョニングサービスによって削除要求が送信されて、アプリからユーザーが完全に削除されます。

属性マッピングに IsSoftDeleted がある場合は、これが使用されて、ユーザーの状態と、active = false を指定した更新要求を送信してユーザーを論理的に削除するかどうかが判別されます。

プロビジョニング解除のイベント

この表に、Microsoft Entra プロビジョニングサービスを使ってプロビジョニング解除アクションを構成する方法が説明されています。これらの規則は、ギャラリー以外またはカスタムのアプリケーションを考慮して記述されていますが、一般的にはギャラリー内のアプリケーションに適用されます。ただし、ギャラリーアプリケーションのビヘイビアーは、アプリケーションのニーズに合わせて最適化されているため、異なる場合があります。たとえば、ターゲットアプリケーションで論理的な削除がサポートされていない場合、Microsoft Entra プロビジョニングサービスは、論理的な削除を送信するのではなく、物理的な削除の要求を送信してユーザーを削除する可能性があります。

シナリオ	Microsoft Entra ID で構成する方法
ユーザーがアプリから割り当て解除されたか、Microsoft Entra ID で論理的に削除されたか、またはサインインがブロックされた。何も実行されないようにする。	属性マッピングから `isSoftDeleted` を削除するか、またはスコープ外の削除をスキップするプロパティを true に設定するか、あるいはその両方を行います。
ユーザーがアプリから割り当て解除されたか、Microsoft Entra ID で論理的に削除されたか、またはサインインがブロックされた。特定の属性を `true` または `false` に設定する必要がある。	false に設定する必要がある属性に `isSoftDeleted` をマップします。
ユーザーが Microsoft Entra ID で無効になったか、アプリから割り当て解除されたか、Microsoft Entra ID で論理的に削除されたか、またはサインインがブロックされた。ターゲットアプリケーションに削除要求を送信する必要がある。	これは現在、この機能を必要とする限定されたギャラリーアプリケーションのセットでサポートされています。顧客がこれを構成することはできません。
ユーザーは Microsoft Entra ID で削除されます。ターゲットアプリケーションで何も実行されないようにする。	属性構成エクスペリエンスで、ターゲットオブジェクトのアクションの 1 つとして "削除" が選択されていないことを確認します。
ユーザーは Microsoft Entra ID で削除されます。ターゲットアプリケーションで属性の値を設定する必要がある。	サポートされていません。
ユーザーは Microsoft Entra ID で削除されます。ターゲットアプリケーションでユーザーを削除する必要がある	属性構成エクスペリエンスで、対象オブジェクトのアクションの 1 つとして [削除] が選択されていることを確認します。

既知の制限事項

ユーザーまたはグループがアプリから割り当て解除され、プロビジョニングサービスで管理されなくなると、無効化要求が送信されます。その時点で、ユーザーはサービスによって管理されておらず、ユーザーがディレクトリから削除されたときに削除要求は送信されません。
Microsoft Entra ID 内で無効になっているユーザーのプロビジョニングはサポートされていません。プロビジョニングされるには、事前に Microsoft Entra ID 内でアクティブになっている必要があります。
ユーザーが論理的に削除された状態からアクティブになると、Microsoft Entra プロビジョニングサービスによってそのユーザーはターゲットアプリ内でアクティブにされますが、グループメンバーシップは自動的には復元されません。ターゲットアプリケーションによって、ユーザーのグループメンバーシップは非アクティブ状態で維持されます。非アクティブ状態の管理がターゲットアプリケーションでサポートされていない場合は、プロビジョニングを再起動してグループメンバーシップを更新することができます。

推奨

アプリケーションを開発する場合は、論理的な削除と物理的な削除の両方を常にサポートしてください。そうすることで、顧客は、ユーザーが誤って無効にされた場合でも回復することができます。

次の手順

自動ユーザープロビジョニングのデプロイを計画する

ギャラリーアプリのプロビジョニングを構成する

独自のアプリを作成するときに SCIM エンドポイントを構築してプロビジョニングを構成する

アプリケーションに対するユーザーの構成およびプロビジョニングに関する問題のトラブルシューティング

Microsoft Entra ID での Microsoft Entra ID でのアプリケーション プロビジョニングのしくみ