組織がアプリケーション プロビジョニングにMicrosoft Entra IDを採用する場合、多くの場合、ターゲット アプリケーションには、プロビジョニングが構成される前に作成されたユーザー アカウントが既に含まれています。 Account Discovery を使用すると、これらの既存のアカウントを検索し、それらをMicrosoft Entra IDユーザーと一致させ、それらを分類して、管理されていない ID をガバナンスの下に持ち込むことができます。 プロビジョニングにオンボードした後、アプリケーション管理者はアプリケーションでアカウントを手動で作成できます。 このレポートを使用すると、組織は、初期オンボード中と運用可能なプロビジョニング後の両方で、ローカルアカウントまたは孤立したアカウントを識別できます。
Account Discovery は、ターゲット アプリケーションからすべてのユーザー アカウントを取得し、次の 3 つのカテゴリに分類します。
- ローカル アカウント — Microsoft Entra IDで一致するユーザーがいないターゲット アプリケーション内のアカウント。 これらのアカウントは、元の従業員、サービス アカウント、別のプロセスを通じてプロビジョニングされたユーザー、またはデータ品質の問題 (不一致や古い属性値など) によって一致しなかったアカウントに属している可能性があります。
- 割り当てられていないユーザー — Microsoft Entra ID ユーザーと一致するが、ユーザーがエンタープライズ アプリケーションに割り当てられていないアカウント。 これらのユーザーはディレクトリに存在しますが、それらを管理するためにプロビジョニングに必要なアプリケーション割り当てがありません。
- 割り当てられたユーザー — エンタープライズ アプリケーションに割り当てられているMicrosoft Entra ID ユーザーと一致するアカウント。 これらのアカウントは、プロビジョニング サービスによって完全に管理されます。
この分類により、アプリケーションにアクセスできるユーザーを把握でき、管理、再割り当て、または削除する必要があるアカウントを特定するのに役立ちます。
前提条件
アカウント検出を使用する前に、次の手順を実行する必要があります。
- Microsoft Entra ID ガバナンス アドオン ライセンスまたは Microsoft Entra スイート。 ライセンス別の機能の可用性の詳細については、Microsoft Entra ID ガバナンス ライセンスの基礎を参照してください。
- 有効な資格情報とテスト接続が成功したプロビジョニング用に構成されたエンタープライズ アプリケーション。
- Microsoft Entra IDとターゲット アプリケーションの間で構成された直接一致する属性マッピング。 アカウント検出では、最初に一致する属性を使用して、2 つのシステム間でユーザーを関連付けます。
- 次のいずれかのロール: アプリケーション管理者、 クラウド アプリケーション管理者、または ハイブリッド ID 管理者。
既知の制限
- アカウントの検出には、ユーザーの相関関係に 直接一致する属性 が必要です。 式ベースの変換は、照合ではサポートされていません。
- 複数の一致する属性が構成されている場合は、 最初 に一致する属性のみが使用されます。
アプリケーションのサポート
SCIM ベースのコネクタの場合、アカウント検出では、アプリケーションで RFC 7644、セクション 3.4.2.4 がサポートされている必要があります。
検出動作が確立されたコネクタ
次のアプリケーションでアカウント検出を使用しているお客様は、一貫して完全な検出結果を受け取ります。
- Atlassian Cloud
- SCIM
- Salesforce
- SAP Cloud Identity Services
- ECMA (SQL、LDAP、Web サービス、PowerShell コネクタを介したオンプレミス アプリケーションのサポートを有効にします)
- GitHub Enterprise Cloud (制限事項については、こちらを参照)
検出をサポートしていないコネクタ
アカウント検出は、次のアプリケーションでは現在サポートされていません。
- HR プロビジョニング (Workday、SAP SuccessFactors、API 主導のプロビジョニング)
- ServiceNow
- アマゾン ウェブ サービス (AWS)
- Snowflake
その他すべてのコネクタ
アカウント検出は、サポートされている他のすべてのコネクタに対して有効にすることができます。 検出の結果は、ターゲット アプリケーションが SCIM API を使用したユーザーの一覧表示と改ページをサポートしているかどうかによって異なる場合があります。 探索レポートの結果が 0 の場合は、属性マッピングで 1 つの直接一致属性 (式なし) が構成されていることを確認します。 次に、SCIM 標準のセクション 3.4.2.4 に 従って、アプリケーションが改ページをサポートしていることをアプリケーション ベンダーに確認します。
ターゲット アプリケーションで ID を検出する
ターゲット アプリケーション内の既存のユーザー アカウントを検出するには:
- 少なくとも Microsoft Entra 管理センターアプリケーション管理者としてサインインします。
- Identity>Applications>Enterprise アプリケーション に移動します。
- ID を検出するアプリケーションを選択します。
- 左側のナビゲーションで、[ プロビジョニング] を選択します。
- プロビジョニング構成に有効な資格情報とテスト接続が成功していることを確認します。
- [ ID の検出] を選択します。
プロビジョニング サービスは、ターゲット アプリケーションからすべてのユーザー アカウントを取得し、カテゴリ別に整理して表示します。 検出には、レポートの生成に少なくとも 30 分かかります。 ターゲット アプリに含まれるアカウントが多いほど、レポートにかかる時間が長くなることに注意してください。 たとえば、250,000 アカウントのアプリケーションでは、検出レポートの生成に 12 時間以上かかる場合があります。
検出されたアカウントを確認する
検出プロセスが完了したら、各カテゴリの結果を確認します。
ローカル アカウント
ローカル アカウントはターゲット アプリケーションに存在しますが、Microsoft Entra IDに一致するユーザーがありません。 これらのアカウントは次を表す場合があります。
- ディレクトリ アカウントが削除されたが、アプリケーション アカウントがプロビジョニング解除されなかった元従業員。
- アプリケーションで直接作成されたサービス アカウントまたは共有アカウント。
- Microsoft Entra IDを使用していない別のプロセスを通じてプロビジョニングされたユーザー。
- 照合処理を妨げるデータ品質の問題が発生しているシナリオ。
これらのアカウントを確認して、ターゲット アプリケーションから削除するか、既存のMicrosoft Entra ID ユーザーと照合するか、as-is保持するかを決定します。
割り当てられていないユーザー
割り当てられていないユーザーは、一致する属性に基づいてMicrosoft Entra IDユーザーと一致しますが、エンタープライズ アプリケーションには割り当てられません。 これらのアカウントをプロビジョニング管理の下に持ち込むには、
- エンタープライズ アプリケーションの [ユーザーとグループ ] ページに移動します。
- 適切なユーザーまたはグループをアプリケーションに割り当てます。
- 割り当て後、プロビジョニング サービスは後続のプロビジョニング サイクルでこれらのアカウントを管理します。
割り当てられたユーザー
割り当てられたユーザーは、既にアプリケーションに割り当てられているMicrosoft Entra IDユーザーと一致します。 これらのアカウントは、プロビジョニング サービスによって完全に管理されます。 属性マッピングを確認または更新しない限り、アクションは必要ありません。
フィルター処理と検索結果
検索機能とフィルター機能を使用して、特定のアカウントを検索します。
- 名前または属性値でアカウントを検索します。
- カテゴリ (ローカル、未割り当て、または割り当て済み) で結果をフィルター処理します。
- ターゲット アプリケーションからインポートされた属性と関連付けの状態を表示する列を管理します。
エンタープライズ アプリケーションやアクセス パッケージに関連付けられたユーザーを割り当てる
アプリケーション内のユーザー を検出 したら、それらのユーザーをエンタープライズ アプリケーションまたはアクセス パッケージに簡単に割り当てることができます。 Assign-CorrelatedUsersWithRules.ps1 ファイルをダウンロードし、PowerShell コマンドレットを実行してユーザーを割り当てます。 スクリプトは PowerShell 7.X で実行する必要があります。
オプションのパラメーター
| パラメーター | Description |
|---|---|
-DryRun |
変更を加えない場合に何が起こるかを示します。 |
-SkipAppRoleAssignment |
アクセス パッケージのみを管理し、アプリ ロールの割り当てをスキップする |
| 重複検出 | 新しい割り当てを作成する前に、既存の割り当てを確認します |
| クライアント側の状態フィルター | API の結果が予想される状態と一致し、API の予測できない挙動から保護することを検証します。 |
-OutputFile |
タイムスタンプ、アクション、エラーの詳細を含む CSV としての完全な監査証跡 |
| 厳格モード |
Set-StrictMode -Version Latest と $ErrorActionPreference = "Stop" を使用して、予期しない問題に迅速に対処するために実行します。 |
シナリオの例
関連付けられたすべてのユーザーをエンタープライズ アプリに割り当てます。
pwsh -File '.\Assign-CorrelatedUsers.ps1' -ServicePrincipalId "7A22..."関連付けられたすべてのユーザーを特定のアクセス パッケージ ( ルール ファイルの例) に割り当てます。
pwsh -File '.\Assign-CorrelatedUsers.ps1' -ServicePrincipalId '7A22...' -RulesFile '.\access-package-rules-internal.csv' -DryRun -OutputFile '.\results-dryrun.csv'定義したルール (ルール ファイルの例) に基づいてユーザーをパッケージに割り当てます。
pwsh -ExecutionPolicy Bypass -File '.\Assign-CorrelatedUsers.ps1' -ServicePrincipalId "7A22..." `-RulesFile ".\access-package-rules.csv"定義されたどのルールにも一致しないユーザー向けに、フォールバック パッケージを使用してユーザーをアクセス パッケージに割り当てます。
pwsh -ExecutionPolicy Bypass -File '.\Assign-CorrelatedUsers.ps1' -ServicePrincipalId "7A22..." `-RulesFile ".\access-package-rules.csv" `-AccessPackageId "fallback-pkg-id" -PolicyId "fallback-policy-id" `-FallbackBehavior UseFallbackユーザーをアクセス パッケージに割り当て、アプリ ロールの割り当てをスキップします。
pwsh -ExecutionPolicy Bypass -File '.\Assign-CorrelatedUsers.ps1' -ServicePrincipalId "7A22..." `-RulesFile ".\access-package-rules.csv" -SkipAppRoleAssignment
ルール ファイルの説明
ルール ファイルは、次の列を含む標準 の CSV です。
| コラム | Purpose |
|---|---|
RuleGroup |
同じグループ番号を共有する行は、一緒に AND で結合されます。 異なるグループは個別に評価されます。 |
PropertyName |
ターゲット SCIM プロパティ バッグ内のキー (例: userType、 urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department)。 プロパティ名は、個々のユーザーのビュー属性をクリックするとき、またはプロビジョニング属性マッピングで検出 UX で見つけることができます。 |
Operator |
eq | ne | contains | startswith | endswith | regex |
Value |
比較対象の値（大文字小文字を区別しません）。 |
AccessPackageId |
グループが一致したときに割り当てるアクセス パッケージ。 これは、Microsoft Entra 管理センター内のアクセス パッケージに移動するときに URL で確認できます。 |
PolicyId |
そのアクセス パッケージの割り当てポリシー。 これは、Microsoft Entra 管理センター内のアクセス パッケージに移動するときに URL で確認できます。 |
アイデンティティガバナンスとの統合
アカウント検出は、Microsoft Entra ID ガバナンス と共に機能し、完全な ID ライフサイクルを管理するのに役立ちます。 ターゲット アプリケーションで ID を検出すると、次のことができます。
- アクセス パッケージに既存のユーザーを割り当てて今後のアクセスを管理し、アクセス パッケージでレビューを実行してアクセスを認定し、ライフサイクル管理を自動化するようにライフサイクル ワークフローを構成します。
- アプリケーションへのアクセスを要求できるユーザーを管理するように エンタイトルメント管理 を構成します。
- ユーザー ライフサイクル イベントに基づいてプロビジョニングとプロビジョニング解除を自動化するようにライフサイクル ワークフロー を設定します。
アプリケーション アクセスの管理の詳細については、「 環境内のアプリケーションのアクセスの管理」を参照してください。
関連するコンテンツ
- エンタープライズ アプリケーションの自動ユーザー プロビジョニングを構成する
アプリケーションプロビジョニングがMicrosoft Entra ID - アプリケーションの一致しないユーザーを管理する
- アプリケーション属性マッピングをカスタマイズする
- Microsoft Entra ID を使用したプロビジョニングとは
アプリケーション開発者向け
アカウント検出がターゲットアプリケーションで動作するためには、アプリケーションがSCIMページネーションをサポートしている必要があります。それはRFC 7644、セクション 3.4.2.4で説明されています。 プロビジョニング サービスは、検出プロセス中にページ分割を使用して、ターゲット アプリケーションからすべてのユーザー アカウントを取得します。