アプリケーションの既存のユーザーを管理する - Microsoft PowerShell

[アーティクル]
01/09/2024

アクセスレビューなどの Microsoft Entra ID Governance 機能でアプリケーションを使う前に、そのアプリケーションの既存のユーザーを Microsoft Entra ID に設定する必要がある一般的なシナリオは 3 つあります。

ライセンスの要件

この機能を使用するには、Microsoft Entra ID ガバナンスライセンスが必要です。要件に適したライセンスを見つけるには、「Microsoft Entra ID ガバナンスライセンスの基礎」をご覧ください。

アプリケーションが独自の ID プロバイダーを使用した後に Microsoft Entra ID に移行された場合

最初のシナリオでは、アプリケーションが既に環境内に存在します。そのアプリケーションは以前、どのユーザーにアクセス権があるかを追跡するために独自の ID プロバイダーまたはデータストアを使用していました。

Microsoft Entra ID に依存するようにアプリケーションを変更すると、Microsoft Entra ID 内に存在し、そのアプリケーションへのアクセスが許可されているユーザーだけがアクセスできます。その構成変更の一部として、そのアプリケーションのデータストアから既存のユーザーを Microsoft Entra ID に取り込むことを選択できます。それにより、それらのユーザーは引き続き Microsoft Entra ID を通してアクセスできます。

アプリケーションに関連付けられているユーザーを Microsoft Entra ID で表されるようにすると、ユーザーとアプリケーションの関係が別の場所で開始された場合でも、Microsoft Entra ID でアプリケーションにアクセスできるユーザーを追跡できます。たとえば、その関係はアプリケーションのデータベースまたはディレクトリで開始されている可能性があります。

Microsoft Entra ID では、ユーザーの割り当てを認識した後、アプリケーションのデータストアに更新を送信できます。この更新には、そのユーザーの属性が変更されたときや、そのユーザーがアプリケーションのスコープから外れたときが含まれます。

Microsoft Entra ID を唯一の ID プロバイダーとして使用しないアプリケーション

2 つ目のシナリオでは、アプリケーションが、その ID プロバイダーとして Microsoft Entra ID のみには依存していません。

場合によっては、アプリケーションが AD グループに依存している場合があります。このシナリオは、「アプリケーションへのユーザーのアクセスのアクセスレビューを準備する」のパターン B で説明されています。この記事で説明されているように、このアプリケーションのプロビジョニングを構成する必要はありません。AD グループのメンバーシップを確認する方法については、代わりにこの記事のパターン B の手順に従ってください。

場合によっては、アプリケーションが複数の ID プロバイダーをサポートしていたり、独自の組み込みの資格情報ストレージを持っていたりすることがあります。このシナリオは、「アプリケーションへのユーザーのアクセスのアクセスレビューを準備する」ではパターン C として説明されています。

アプリケーションから他の ID プロバイダーまたはローカル資格情報認証を削除することが不可能な場合があります。その場合、Microsoft Entra ID を使用してそのアプリケーションにアクセスできるユーザーをレビューしたり、そのアプリケーションからだれかのアクセス権を削除したりするには、認証を Microsoft Entra ID に依存しないアプリケーションユーザーを表す Microsoft Entra ID 内の割り当てを作成する必要があります。

アクセスレビューの一環として、アプリケーションにアクセスするすべてのユーザーをレビューする予定の場合は、これらの割り当てが必要です。

たとえば、あるユーザーがアプリケーションのデータストアに存在するとします。 Microsoft Entra ID は、アプリケーションへのロールの割り当てを必要とするように構成されています。ただし、そのユーザーは Microsoft Entra ID にアプリケーションロールの割り当てを持っていません。

そのユーザーが Microsoft Entra ID で更新されても、アプリケーションに変更は送信されません。また、アプリケーションのロール割り当てがレビューされた場合も、そのユーザーはレビューに含まれません。すべてのユーザーがレビューに含まれるようにするには、アプリケーションのすべてのユーザーに対してアプリケーションロールの割り当てを設定する必要があります。

アプリケーションが ID プロバイダーとして Microsoft Entra ID を使用しておらず、プロビジョニングもサポートしていない

レガシアプリケーションによっては、アプリケーションから他の ID プロバイダーまたはローカル資格情報の認証を削除することや、それらのアプリケーションのプロビジョニングプロトコルのサポートを有効にすることができない場合があります。

このようなプロビジョニングプロトコルをサポートしないアプリケーションのシナリオについては、プロビジョニングをサポートしないアプリケーションの既存ユーザーの管理に関する別の記事を参照してください。

用語

この記事では、Microsoft Graph PowerShell コマンドレットを使用して、アプリケーションロールの割り当てを管理するためのプロセスを示しています。ここでは、次の Microsoft Graph の用語を使用しています。

Microsoft Graph の用語を示す図。

Microsoft Entra ID では、サービスプリンシパル (ServicePrincipal) は、特定の組織のディレクトリ内のアプリケーションを表します。 ServicePrincipal には、アプリケーションがサポートするロール (Marketing specialist など) を一覧表示する AppRoles という名前のプロパティがあります。 AppRoleAssignment はユーザーをサービスプリンシパルにリンクし、そのユーザーのそのアプリケーションでのロールを指定します。アプリケーションへのシングルサインオンとアプリケーションへのプロビジョニングが個別に処理される場合、アプリケーションは複数のサービスプリンシパルを持つことができます。

ユーザーにアプリケーションへの期間限定のアクセス権を付与するために、Microsoft Entra エンタイトルメント管理アクセスパッケージを使用することもできます。エンタイトルメント管理では、AccessPackage に 1 つ以上のリソースロール (複数のサービスプリンシパルの可能性もあります) が含まれています。 AccessPackage には、アクセスパッケージへのユーザーの割り当て (Assignment) も含まれています。

アクセスパッケージへのユーザーの割り当てを作成すると、Microsoft Entra エンタイトルメント管理によって、各アプリケーションのアクセスパッケージ内のサービスプリンシパルに対してユーザーに必要な AppRoleAssignment インスタンスが自動的に作成されます。詳細については、PowerShell を使用してアクセスパッケージを作成する方法を示す、Microsoft Entra エンタイトルメント管理でリソースへのアクセスを管理する方法に関するページ参照してください。

開始する前に

テナントには次のいずれかのライセンスが必要です。
- Microsoft Entra ID P2 または Microsoft Entra ID Governance
- Enterprise Mobility + Security E5 ライセンス
適切な管理者ロールを持っている必要があります。これらの手順を初めて実行している場合は、テナントでの Microsoft Graph PowerShell の使用を認可するグローバル管理者ロールが必要です。
アプリケーションには、テナント内に少なくとも 1 つのサービスプリンシパルが必要です。
- アプリケーションで LDAP ディレクトリを使用する場合は、ユーザーを LDAP ディレクトリにプロビジョニングするように Microsoft Entra ID を構成するためのガイドの「Microsoft Entra Connect プロビジョニングエージェントパッケージのダウンロード、インストール、構成」セクションに従います。
- アプリケーションで SQL データベースを使用する場合は、ユーザーを SQL ベースのアプリケーションにプロビジョニングするように Microsoft Entra ID を構成するためのガイドの「Microsoft Entra Connect プロビジョニングエージェントパッケージのダウンロード、インストール、構成」セクションに従います。
- アプリケーションが SAP Cloud Identity Services を使っているか、SCIM プロトコルをサポートするクラウドアプリケーションであり、アプリケーションがテナントにまだ構成されていない場合は、このガイドの後半でアプリケーションギャラリーからアプリケーションを登録します。
- アプリケーションがオンプレミスであり、SCIM プロトコルをサポートしている場合は、オンプレミスの SCIM ベースアプリケーションにユーザーをプロビジョニングするように Microsoft Entra ID を構成する際のガイドに従ってください。

アプリケーションから既存のユーザーを収集する

すべてのユーザーが確実に Microsoft Entra ID に記録されるようにするための最初の手順は、アプリケーションにアクセスできる既存のユーザーのリストを収集することです。

アプリケーションによっては、現在のユーザーの一覧をデータストアからエクスポートするための組み込みのコマンドを備えている場合があります。その他、アプリケーションが外部のディレクトリまたはデータベースに依存する場合もあります。

一部の環境では、アプリケーションが、Microsoft Entra ID へのアクセスを管理するために適さないネットワークセグメントまたはシステムに配置されていることがあります。そのため、そのディレクトリまたはデータベースからユーザーの一覧を抽出し、それをファイルとして Microsoft Entra とのやり取りに使用できる別のシステムに転送することが必要になる場合があります。

このセクションでは、コンマ区切り値 (CSV) ファイル内のユーザーの一覧を取得する 4 つの方法について説明します。

LDAP ディレクトリから
SQL Server データベースから
別の SQL ベースのデータベースから
SAP Cloud Identity Services から

LDAP ディレクトリを使用するアプリケーションから既存のユーザーを収集する

このセクションは、Microsoft Entra ID に対して認証されないユーザーの基になるデータストアとして LDAP ディレクトリを使用するアプリケーションに適用されます。 Active Directory などの多くの LDAP ディレクトリには、ユーザーの一覧を出力するコマンドが含まれています。

そのディレクトリ内のユーザーのうちのどれだけが、アプリケーションのユーザーとしてのスコープ内に存在するかを識別します。この選択は、アプリケーションの構成によって異なります。一部のアプリケーションでは、LDAP ディレクトリに存在するすべてのユーザーが有効なユーザーとなります。他のアプリケーションでは、ユーザーが特定の属性を持っているか、またはそのディレクトリ内のグループのメンバーであることが必要な場合もあります。
ディレクトリからそのユーザーのサブセットを取得するコマンドを実行します。その出力には、Microsoft Entra ID との照合に使用されるユーザーの属性が必ず含まれるようにしてください。これらの属性の例には、従業員 ID、アカウント名、電子メールアドレスなどがあります。

たとえば、次のコマンドでは、LDAP ディレクトリ内のすべてのユーザーの userPrincipalName 属性を含む CSV ファイルを現在のファイルシステムディレクトリ内に生成します。
```
$out_filename = ".\users.csv"
csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"
```
必要に応じて、ユーザーの一覧を含む CSV ファイルを Microsoft Graph PowerShell コマンドレットがインストールされているシステムに転送します。
引き続き、この記事の後の方にある「Microsoft Entra ID にアプリケーションのユーザーに一致するユーザーが存在することを確認する」セクションを参照してください。

SQL Server ウィザードを使用してアプリケーションのデータベーステーブルから既存のユーザーを収集する

このセクションは、基になるデータストアとして SQL Server を使用するアプリケーションに適用されます。

まず、テーブルからユーザーの一覧を取得します。ほとんどのデータベースは、テーブルの内容を CSV ファイルなどの標準ファイル形式にエクスポートする方法を提供しています。アプリケーションで SQL Server データベースが使用されている場合は、SQL Server インポートおよびエクスポートウィザードを使用して、データベースの一部をエクスポートすることができます。データベース用のユーティリティがない場合は、次のセクションで説明されているように、PowerShell で ODBC ドライバーを使用できます。

SQL Server がインストールされているシステムにログインします。
SQL Server 2019 のインポートとエクスポー (64 ビット) またはデータベース用の同等のツールを開きます。
ソースとして既存のデータベースを選択します。
変換先として、[フラットファイル変換先] を選択します。ファイル名を指定し、[コードページ] 値を [65001 (UTF-8)] に変更します。
ウィザードを完了し、すぐに実行するオプションを選択します。
実行が完了するまで待ちます。
必要に応じて、ユーザーの一覧を含む CSV ファイルを Microsoft Graph PowerShell コマンドレットがインストールされているシステムに転送します。
引き続き、この記事の後の方にある「Microsoft Entra ID にアプリケーションのユーザーに一致するユーザーが存在することを確認する」セクションを参照してください。

PowerShell を使用してアプリケーションのデータベーステーブルから既存のユーザーを収集する

このセクションは、基になるデータストアとして別の SQL データベースを使用するアプリケーションに適用されます。そこでは、ECMA Connector Host を使用して、そのアプリケーションにユーザーをプロビジョニングしています。プロビジョニングエージェントがまだ構成されていない場合は、そのガイドを使用して、このセクションで使用する DSN 接続ファイルを作成します。

プロビジョニングエージェントがインストールされている、またはインストールする予定のシステムにログインします。
PowerShell を開きます。
データベースシステムに接続するための接続文字列を構築します。

接続文字列のコンポーネントは、データベースの要件によって異なります。 SQL Server を使用している場合は、DSN と接続文字列のキーワードと属性の一覧を参照してください。

別のデータベースを使用している場合は、そのデータベースに接続するための必須キーワードを含める必要があります。たとえば、データベースで DSN ファイルの完全修飾パス名、ユーザー ID、パスワードを使用している場合は、次のコマンドを使用して接続文字列を作成します。
```
$filedsn = "c:\users\administrator\documents\db.dsn"
$db_cs = "filedsn=" + $filedsn + ";uid=p;pwd=secret"
```
次のコマンドを使用して、データベースへの接続を開き、接続文字列を指定します。
```
$db_conn = New-Object data.odbc.OdbcConnection
$db_conn.ConnectionString = $db_cs
$db_conn.Open()
```
データベーステーブルからユーザーを取得する SQL クエリを作成します。アプリケーションのデータベース内のユーザーを Microsoft Entra ID 内のユーザーと照合するために使用される列を必ず含めてください。これらの列には、従業員 ID、アカウント名、電子メールアドレスなどが含まれることがあります。

たとえば、ユーザーが列 name と email を含む USERS という名前のデータベーステーブル内に保持されている場合は、次のコマンドを入力します。
```
$db_query = "SELECT name,email from USERS"
```
このクエリを接続経由でデータベースに送信します。
```
$result = (new-object data.odbc.OdbcCommand($db_query,$db_conn)).ExecuteReader()
$table = new-object System.Data.DataTable
$table.Load($result)
```
その結果は、クエリから取得されたユーザーを表す行の一覧です。

結果を CSV ファイルに書き込みます。

$out_filename = ".\users.csv"
$table.Rows | Export-Csv -Path $out_filename -NoTypeInformation -Encoding UTF8

このシステムに Microsoft Graph PowerShell コマンドレットがインストールされていないか、または Microsoft Entra ID への接続がない場合は、ユーザーのリストを含む CSV ファイルを Microsoft Graph PowerShell コマンドレットがインストールされているシステムに転送します。

SAP Cloud Identity Services から既存のユーザーを収集する

このセクションは、ユーザープロビジョニングの基となるサービスとして SAP Cloud Identity Services を使う SAP アプリケーションに適用されます。

SAP Cloud Identity Services 管理コンソール、https://<tenantID>.accounts.ondemand.com/admin、または試用版の場合には https://<tenantID>.trial-accounts.ondemand.com/admin にサインインします。
[ユーザーと認可] > [ユーザーのエクスポート] に移動します。
Microsoft Entra ユーザーを SAP のユーザーと照合するために必要なすべての属性を選択します。これには、SAP システムで使っている可能性のある SCIM ID、userName、emails、その他の属性が含まれます。
[エクスポート] を選択し、ブラウザーが CSV ファイルをダウンロードするまで待ちます。
このシステムに Microsoft Graph PowerShell コマンドレットがインストールされていないか、または Microsoft Entra ID への接続がない場合は、ユーザーのリストを含む CSV ファイルを Microsoft Graph PowerShell コマンドレットがインストールされているシステムに転送します。

Microsoft Entra ID にアプリケーションのユーザーに一致するユーザーが存在することを確認する

これで、アプリケーションから取得されたすべてのユーザーのリストが用意できたので、アプリケーションのデータストアのユーザーを Microsoft Entra ID 内のユーザーと照合します。

先に進む前に、ソースシステムとターゲットシステム内のユーザーの照合に関する情報を確認します。後で、同等のマッピングを使用して Microsoft Entra プロビジョニングを構成します。このステップにより、同じ照合ルールを使用して、Microsoft Entra プロビジョニングでアプリケーションのデータストアに対してクエリを実行することができるようになります。

Microsoft Entra ID でユーザーの ID を取得する

このセクションでは、Microsoft Graph PowerShell コマンドレットを使用して Microsoft Entra ID を操作する方法を示します。

このシナリオのために組織でこれらのコマンドレットを初めて使用する場合は、テナントで Microsoft Graph PowerShell を使用できるように、グローバル管理者ロールである必要があります。以降の操作では、次のような低い特権のロールを使用できます。

ユーザー管理者、新しいユーザーの作成が予測される場合。
アプリケーション管理者または ID ガバナンス管理者、アプリケーションロールの割り当ての管理だけを行う場合。

PowerShell を開きます。
Microsoft Graph PowerShell モジュールがまだインストールされていない場合は、次のコマンドを使用して Microsoft.Graph.Users モジュールなどをインストールします。
```
Install-Module Microsoft.Graph
```
これらのモジュールが既にインストールされている場合は、最新バージョンを使用していることを確認します。
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

Microsoft Entra ID に接続します。

$msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

このコマンドを初めて使用する場合は、Microsoft Graph コマンドラインツールにこれらのアクセス許可を付与することを許可する必要があります。
アプリケーションのデータストアから取得したユーザーの一覧を、PowerShell セッションに読み込みます。ユーザーの一覧の形式が CSV ファイルであった場合は、PowerShell コマンドレット Import-Csv を使用し、引数として前のセクションのファイルの名前を指定できます。

たとえば、SAP Cloud Identity Services から取得したファイル名が Users-exported-from-sap.csv で、現在のディレクトリにある場合は、次のコマンドを入力します。
```
$filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
別の例として、データベースまたはディレクトリを使用している場合、ファイル名が users.csv で、現在のディレクトリにある場合は、次のコマンドを入力します:
```
$filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Microsoft Entra ID 内のユーザーの属性に一致する users.csv ファイルの列を選択します。

SAP Cloud Identity Services を使用している場合、既定のマッピングは、Microsoft Entra ID 属性が userPrincipalName の SAP SCIM 属性 userName です:
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
別の例として、データベースやディレクトリを使用している場合、EMail という列の値が Microsoft Entra の属性 userPrincipalName と同じ値であるデータベース内のユーザーがいる場合があります:
```
$db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"
```

Microsoft Entra ID でこれらのユーザーの ID を取得します。

次の PowerShell スクリプトでは、前に指定された $dbusers、$db_match_column_name、$azuread_match_attr_name の各値を使用します。これは、Microsoft Entra ID にクエリを実行して、ソースファイル内の各レコードに一致する値の属性を持つユーザーを見つけます。ソース SAP Cloud Identity Services、データベース、またはディレクトリから取得したファイルに多数のユーザーが存在する場合、このスクリプトが完了するまでに数分かかる場合があります。この値を持つ属性が Microsoft Entra ID に存在せず、contains などのフィルター式を使用する必要がある場合は、このスクリプトと後の手順 11 のスクリプトを、別のフィルター式を使用するようにカスタマイズする必要があります。

$dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

前のクエリの結果を表示します。エラーまたは一致が見つからないために、SAP Cloud Identity Services、データベース、またはディレクトリのいずれかのユーザーが Microsoft Entra ID に配置できなかったかどうかを確認します。

次の PowerShell スクリプトでは、見つからなかったレコードの数を表示します。

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Error "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

このスクリプトは、完了時に、データソースのいずれかのレコードが Microsoft Entra ID に見つからなかった場合はエラーを示します。アプリケーションのデータストアのユーザーのレコードのうち Microsoft Entra ID 内のユーザーとして見つからなかったものがある場合は、どのレコードが一致しなかったのかとその理由を調査する必要があります。

たとえば、ユーザーのメールアドレスと userPrincipalName が Microsoft Entra ID で変更されたのに、アプリケーションのデータソースでそれに対応する mail プロパティが更新されていない可能性があります。または、ユーザーは既に組織を離れているが、まだアプリケーションのデータソースに存在する可能性があります。あるいは、アプリケーションのデータソースに、Microsoft Entra ID 内のどの特定のユーザーにも対応していないベンダーまたはスーパー管理者アカウントが存在する可能性もあります。
Microsoft Entra ID で見つけられなかったか、またはアクティブかつサインインできる状態でなかったユーザーが存在したが、そのアクセスをレビューしたり、その属性を SAP Cloud Identity Services、データベース、またはディレクトリで更新したい場合は、アプリケーションまたは照合ルールを更新するか、そのユーザー用の Microsoft Entra ユーザーを更新する必要があります。どの変更を行うかの詳細については、「Microsoft Entra ID のユーザーと一致しなかったアプリケーションのマッピングとユーザーアカウントを管理する」を参照してください。

Microsoft Entra ID でユーザーを作成するオプションを選択した場合、次のいずれかを使用してユーザーを一括で作成できます。
- CSV ファイル (「Microsoft Entra 管理センターでのユーザーの一括作成」で説明されています)
- New-MgUser コマンドレット
これらの新しいユーザーに、Microsoft Entra ID が後でアプリケーション内の既存のユーザーと一致するために必要な属性と、Microsoft Entra ID で必要な属性 (userPrincipalName、mailNickname、displayName を含む) が設定されていることを確認します。 userPrincipalName は、ディレクトリ内のすべてのユーザー間で一意である必要があります。

たとえば、EMail という名前の列の値が Microsoft Entra のユーザープリンシパル名として使用したい値であり、列 Alias の値に Microsoft Entra ID のメールニックネームが含まれ、列 Full name の値にユーザーの表示名が含まれているようなユーザーが、データベースに存在する場合があります。
```
$db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"
```
そのような場合、このスクリプトを使用して、SAP Cloud Identity Services、データベース、またはディレクトリにある Microsoft Entra ID のユーザと一致しなかったユーザに対して Microsoft Entra ユーザを作成できます。組織で必要な Microsoft Entra 属性をさらに追加するため、または $azuread_match_attr_name が mailNickname でも userPrincipalName でもない場合にその Microsoft Entra 属性を指定するために、このスクリプトの変更が必要になる場合があることに注意してください。
```
$dbu_missing_columns_list = @()
$dbu_creation_failed_list = @()
foreach ($dbu in $dbu_not_matched_list) {
   if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
      $params = @{
         accountEnabled = $false
         displayName = $dbu.$db_display_name_column_name
         mailNickname = $dbu.$db_mail_nickname_column_name
         userPrincipalName = $dbu.$db_user_principal_name_column_name
         passwordProfile = @{
           Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
         }
      }
      try {
        New-MgUser -BodyParameter $params
      } catch { $dbu_creation_failed_list += $dbu; throw }
   } else {
      $dbu_missing_columns_list += $dbu
   }
}
```

不足しているすべてのユーザーを Microsoft Entra ID に追加したら、手順 7 のスクリプトをもう一度実行します。次に、手順 8 のスクリプトを実行します。エラーが報告されていないことを確認します。

$dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Warning "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count -ne 0) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

アプリケーションを登録する

アプリケーションが既に Microsoft Entra ID に登録されている場合は、次の手順に進みます。

アプリケーションが LDAP ディレクトリを使っている場合は、ユーザーを LDAP ディレクトリにプロビジョニングするように Microsoft Entra ID を構成する際のガイドのセクションに従って、オンプレミスの ECMA アプリ用の新しい登録を Microsoft Entra ID に作成します。
アプリケーションが SQL データベースを使っている場合は、ユーザーを SQL ベースのアプリケーションにプロビジョニングするように Microsoft Entra ID を構成する際のガイドのセクションに従って、オンプレミスの ECMA アプリ用の新しい登録を Microsoft Entra ID に作成します。
SAP Cloud Identity Services を使っている場合は、SAP Cloud Identity Services にユーザーをプロビジョニングするための Microsoft Entra ID の構成ガイドに従います。
SCIM プロトコルをサポートするクラウドアプリケーションである場合は、アプリケーションギャラリーからアプリケーションを追加することができます。
アプリケーションがオンプレミスであり、SCIM プロトコルをサポートしている場合は、オンプレミスの SCIM ベースアプリケーションにユーザーをプロビジョニングするように Microsoft Entra ID を構成する際のガイドに従ってください。

アプリケーションにまだ割り当てられていないユーザーを確認する

前の手順では、アプリケーションのデータストア内のすべてのユーザーが Microsoft Entra ID のユーザーとして存在することを確認しました。ただし、そのすべてが現在、Microsoft Entra ID でアプリケーションのロールに割り当てられているとは限りません。そこで、次のステップでは、アプリケーションロールに割り当てられていないユーザーがいないかを確認します。

アプリケーションのサービスプリンシパルのサービスプリンシパル ID を検索します。 LDAP ディレクトリまたは SQL データベースを使うアプリケーションのサービスプリンシパルを最近作成した場合は、そのサービスプリンシパルの名前を使います。

たとえば、エンタープライズアプリケーションの名前が CORPDB1 である場合は、次のコマンドを入力します。
```
$azuread_app_name = "CORPDB1"
$azuread_sp_filter = "displayName eq '" + ($azuread_app_name -replace "'","''") + "'"
$azuread_sp = Get-MgServicePrincipal -Filter $azuread_sp_filter -All
```
Microsoft Entra ID で現在アプリケーションに割り当てられているユーザーを取得します。

これは前のコマンドで設定した $azuread_sp 変数に基づいています。
```
$azuread_existing_assignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)
```
前のセクションのユーザー ID の一覧を、現在アプリケーションに割り当てられているユーザーと比較します。
```
$azuread_not_in_role_list = @()
foreach ($id in $azuread_match_id_list) {
   $found = $false
   foreach ($existing in $azuread_existing_assignments) {
      if ($existing.principalId -eq $id) {
         $found = $true; break;
      }
   }
   if ($found -eq $false) { $azuread_not_in_role_list += $id }
}
$azuread_not_in_role_count = $azuread_not_in_role_list.Count
Write-Output "$azuread_not_in_role_count users in the application's data store are not assigned to the application roles."
```
アプリケーションロールに割り当てられていないユーザーの数が 0 で、すべてのユーザーがアプリケーションロールに割り当てられていることを示している場合は、アクセスレビューを実行する前にそれ以上の変更を行う必要はありません。

ただし、1 人以上のユーザーが現在アプリケーションロールに割り当てられていない場合は、手順を続行して、それらをいずれかのアプリケーションのロールに追加する必要があります。
残りのユーザーを割り当てるアプリケーションロールを選択します。

1 つのアプリケーションが複数のロールを持つことができます。また、1 つのサービスプリンシパルが追加のロールを持つことができます。このコマンドを使って、サービスプリンシパルの使用できるロールを一覧表示します。
```
$azuread_sp.AppRoles | where-object {$_.AllowedMemberTypes -contains "User"} | ft DisplayName,Id
```
一覧から適切なロールを選択し、そのロール ID を取得します。たとえば、ロール名が Admin である場合は、次の PowerShell コマンドでその値を指定します。
```
$azuread_app_role_name = "Admin"
$azuread_app_role_id = ($azuread_sp.AppRoles | where-object {$_.AllowedMemberTypes -contains "User" -and $_.DisplayName -eq $azuread_app_role_name}).Id
if ($null -eq $azuread_app_role_id) { write-error "role $azuread_app_role_name not located in application manifest"}
```

アプリケーションのプロビジョニングを構成する

アプリケーションが LDAP ディレクトリ、SQL データベース、または SAP Cloud Identity Services を使っている場合、または SCIM をサポートしている場合は、新しい割り当てを作成する前に、アプリケーションに対する Microsoft Entra ユーザーのプロビジョニングを構成します。割り当てを作成する前にプロビジョニングを構成すると、Microsoft Entra ID のユーザーを、アプリケーションのデータストアにすでに存在するユーザーに割り当てられたアプリケーションのロールと照合することができます。プロビジョニングするオンプレミスのディレクトリまたはデータベースがアプリケーションにあり、さらにフェデレーション SSO をサポートしている場合は、ディレクトリ内のアプリケーションを表す 2 つのサービスプリンシパル (プロビジョニング用に 1 つと SSO 用に 1 つ) が必要になることがあります。アプリケーションがプロビジョニングをサポートしていない場合は、次のセクションに進んでください。

選択したユーザーのみがアプリケーションにプロビジョニングされるよう、ユーザーにアプリケーションロールの割り当てを要求するようにアプリケーションが構成されていることを確認します。
アプリケーションへのプロビジョニングが構成されていない場合は、それをここで構成します (ただし、またプロビジョニングは開始しません)。
- アプリケーションで LDAP ディレクトリを使用する場合は、ユーザーを LDAP ディレクトリにプロビジョニングするように Microsoft Entra ID を構成するためのガイドに従います。
- アプリケーションで SQL データベースを使用する場合は、ユーザーを SQL ベースのアプリケーションにプロビジョニングするように Microsoft Entra ID を構成するためのガイドに従います。
- アプリケーションが SAP Cloud Identity Services を使う場合は、SAP Cloud Identity Services にユーザーをプロビジョニングするための Microsoft Entra ID の構成ガイドに従います。
- 他のアプリケーションの場合は、次の手順 1 から 3 に従って、Graph API を介してプロビジョニングを構成します。
アプリケーションの [プロパティ] タブを選択します。 [ユーザーの割り当てが必要ですか?] オプションが [はい] に設定されていることを確認します。 [いいえ] に設定されている場合は、外部 ID を含むディレクトリ内のすべてのユーザーがアプリケーションにアクセスでき、アプリケーションへのアクセスをレビューすることはできません。
そのアプリケーションへのプロビジョニングの属性マッピングを確認します。照合のために前のセクションで使用した Microsoft Entra の属性と列に対して [この属性を使用してオブジェクトを照合する] が設定されていることを確認します。

これらの規則で、以前に使用したものと同じ属性が使用されていない場合は、アプリケーションロールの割り当てが作成されるときに、Microsoft Entra ID がアプリケーションのデータストアで既存のユーザーを見つけられない可能性があります。その場合は、Microsoft Entra ID によって、重複したユーザーが誤って作成されることがあります。
アプリケーションの属性に isSoftDeleted の属性マッピングがあることを確認します。

ユーザーがアプリケーションから割り当て解除されるか、Microsoft Entra ID で論理的に削除されるか、またはサインインからブロックされると、Microsoft Entra プロビジョニングでは isSoftDeleted にマップされた属性が更新されます。マップされた属性がない場合、後でアプリケーションロールから割り当て解除されたユーザーは、引き続きアプリケーションのデータストアに存在します。
アプリケーションのプロビジョニングが既に有効になっている場合は、アプリケーションのプロビジョニングが検疫状態になっていないことを確認します。先に進む前に、検疫の原因となっている問題をすべて解決します。

Microsoft Entra ID でアプリロールの割り当てを作成する

Microsoft Entra ID でアプリケーション内のユーザーを Microsoft Entra ID 内のユーザーと照合するには、Microsoft Entra ID でアプリケーションロールの割り当てを作成する必要があります。各アプリケーションロールの割り当てにより、1 つのサービスプリンシパルの 1 つのアプリケーションロールに 1 人のユーザーが関連付けられます。

ユーザーのアプリケーションロールの割り当てが Microsoft Entra ID に作成されており、アプリケーションがプロビジョニングをサポートしている場合は、次のようになります。

Microsoft Entra ID は、SCIM、またはそのディレクトリまたはデータベースを介してアプリケーションにクエリを実行し、ユーザーが既に存在するかどうかを判断します。
その後、Microsoft Entra ID でユーザーの属性が更新されると、Microsoft Entra ID はそれらの更新をアプリケーションに送信します。
ユーザーは、Microsoft Entra ID の外部で更新されない限り、または Microsoft Entra ID 内の割り当てが削除されるまで無期限にアプリケーション内に残ります。
そのアプリケーションのロールの割り当ての次回のアクセスレビューでは、そのユーザーがアクセスレビューに含まれます。
アクセスレビューでユーザーが拒否された場合、そのアプリケーションロールの割り当ては削除されます。 Microsoft Entra ID では、ユーザーがサインインからブロックされことをアプリケーションに通知します。

アプリケーションがプロビジョニングをサポートしていない場合は、次のようになります

ユーザーは、Microsoft Entra ID の外部で更新されない限り、または Microsoft Entra ID 内の割り当てが削除されるまで無期限にアプリケーション内に残ります。
そのアプリケーションのロール割り当ての次回のレビューでは、そのユーザーがレビューに含まれます。
アクセスレビューでユーザーが拒否された場合、そのアプリケーションロールの割り当ては削除されます。ユーザーは Microsoft Entra ID からアプリケーションにサインインできなくなります。

現在ロールの割り当てがないユーザーに対してアプリケーションロールの割り当てを作成します。

foreach ($u in $azuread_not_in_role_list) {
   $res = New-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -AppRoleId $azuread_app_role_id -PrincipalId $u -ResourceId $azuread_sp.Id 
}

変更が Microsoft Entra ID 内で伝達されるまで 1 分待ちます。

Microsoft Entra プロビジョニングが既存のユーザーと一致していることを確認する

Microsoft Entra ID にクエリを実行して、ロールの割り当ての更新された一覧を取得します。
```
$azuread_existing_assignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)
```

前のセクションのユーザー ID の一覧を、現在アプリケーションに割り当てられているユーザーと比較します。

$azuread_still_not_in_role_list = @()
foreach ($id in $azuread_match_id_list) {
   $found = $false
   foreach ($existing in $azuread_existing_assignments) {
      if ($existing.principalId -eq $id) {
         $found = $true; break;
      }
   }
   if ($found -eq $false) { $azuread_still_not_in_role_list += $id }
}
$azuread_still_not_in_role_count = $azuread_still_not_in_role_list.Count
if ($azuread_still_not_in_role_count -gt 0) {
   Write-Output "$azuread_still_not_in_role_count users in the application's data store are not assigned to the application roles."
}

アプリケーションロールに割り当てられているユーザーがいない場合は、Microsoft Entra 監査ログで前のステップのエラーを確認します。

アプリケーションサービスプリンシパルがプロビジョニング用に構成されており、サービスプリンシパルの [プロビジョニング状態] が [オフ] の場合は、それを [オン] にします。 Graph API を使ってプロビジョニングを開始することもできます。
「ユーザーをプロビジョニングするにはどのくらいの時間がかかりますか」というガイダンスに基づき、Microsoft Entra プロビジョニングによって、アプリケーションの既存のユーザーと割り当てられたばかりのユーザーが照合されるのを待ちます。
ポータルまたは Graph API を使ってプロビジョニングの状態を監視し、すべてのユーザーが正常に一致したことを確認します。

プロビジョニングされているユーザーが表示されない場合は、ユーザーがプロビジョニングされていない問題に関するトラブルシューティングガイドを確認してください。プロビジョニング状態にエラーが表示され、オンプレミスアプリケーションにプロビジョニングしている場合は、オンプレミスアプリケーションのプロビジョニングに関するトラブルシューティングガイドを確認してください。
Microsoft Entra 管理センターまたは Graph API 経由でプロビジョニングログを確認します。ログを状態 [失敗] でフィルター処理します。 DuplicateTargetEntries のエラーコードで失敗が発生している場合、これはプロビジョニング照合規則でのあいまいさを示しており、各 Microsoft Entra ユーザーが確実に 1 人のアプリケーションユーザーに一致するように Microsoft Entra ユーザーまたは照合に使用されているマッピングを更新する必要があります。次に、ログをアクション [作成] と状態 [スキップ済み] でフィルター処理します。ユーザーが NotEffectivelyEntitled の SkipReason コードでスキップされた場合、これは、ユーザーアカウントの状態が [無効] であったために Microsoft Entra ID 内のユーザーアカウントが一致しなかったことを示している可能性があります。

作成したアプリケーションロールの割り当てに基づいて Microsoft Entra プロビジョニングサービスがユーザーの照合を完了すると、それらのユーザーに対する以降の変更はアプリケーションに送信されます。

適切なレビュー担当者を選択する

各アクセスレビューを作成するとき、管理者は 1 人以上のレビュー担当者を選ぶことができます。レビュー担当者は、レビューを実行し、リソースに継続的にアクセスするユーザーを選択または削除することができます。

通常は、リソースの所有者がレビューの実行を担当します。パターン B で統合されたアプリケーションのアクセスレビューの一環として、グループのレビューを作成する場合は、グループ所有者をレビュー担当者として選択できます。 Microsoft Entra ID のアプリケーションには所有者がいるとは限らないため、アプリケーションの所有者をレビュー担当者として選択することはできません。代わりに、レビューを作成するときに、アプリケーション所有者の名前をレビュー担当者として指定できます。

グループまたはアプリケーションのレビューを作成するときに、複数ステージのレビューの作成を選ぶこともできます。たとえば、割り当てられた各ユーザーのマネージャーがレビューの最初のステージを実行し、リソース所有者が 2 番目のステージを実行するようにできます。こうすることで、リソース所有者は、マネージャーによって既に承認されているユーザーに集中できます。

レビューを作成する前に、テナントに十分な Microsoft Entra ID P2 または Microsoft Entra ID ガバナンス SKU シートがあることを確認します。また、すべてのレビュー担当者がメールアドレスを持つアクティブなユーザーであることを確認します。アクセスレビューが始まったら、各自が Microsoft Entra ID からのメールをレビューします。レビュー担当者がメールボックスを持っていない場合、レビュー開始時のメールまたはメールリマインダーを受け取りません。また、Microsoft Entra ID へのサインインをブロックされている場合は、レビューを実行できません。

アクセスレビューまたはエンタイトルメント管理を構成する

ユーザーにアプリケーションロールを割り当て、レビュー担当者を指定したら、アクセスレビューまたはエンタイトルメント管理を使用して、それらのユーザーと、アクセスを必要とするその他のユーザーを管理できるようになります。

アプリケーションが持っているアプリケーションロールが 1 つのみであり、アプリケーションはディレクトリ内の 1 つのサービスプリンシパルによって表され、アプリケーションにアクセスする必要があるユーザーが他にいない場合は、次のセクションに進み、アクセスレビューを使用して既存のアクセスをレビューし削除します。
それ以外の場合は、この記事の「エンタイトルメント管理を使用してアクセスを管理する」のセクションに進みます。

アプリロールの割り当てのアクセスレビューを使用して既存のアクセスをレビューおよび削除する

アプリケーションに複数のアプリケーションロールがあり、複数のサービスプリンシパルで表されている場合、またはユーザーがアプリケーションへのアクセスを要求または割り当てるプロセスを用意する場合は、この記事の次のセクションに進み、エンタイトルメント管理を使用してアクセスを管理します。

既存のユーザーがアプリケーションロールに割り当てられているので、これらの割り当てのレビューを開始するように Microsoft Entra ID を構成できます。

このステップを行うには、Global administrator または Identity Governance administrator ロールである必要があります。
グループまたはアプリケーションのアクセスレビューの作成に関するガイドの指示に従って、アプリケーションのロール割り当てのレビューを作成します。完了時に結果を適用するようにレビューを構成します。「ID ガバナンス用の Microsoft Graph PowerShell コマンドレット」モジュールの New-MgIdentityGovernanceAccessReviewDefinition コマンドレットで PowerShell でアクセスレビューを作成することができます。詳細については、例を参照してください。

Note

アクセスレビューの作成時にレビュー判断ヘルパーを有効にした場合、ユーザーが Microsoft Entra ID を使用してアプリケーションに最後にサインインした日時に応じて、判断ヘルパーの推奨事項は 30 日間の間隔に基づいて決まります。
アクセスレビューの開始時には、レビュー担当者に入力するよう依頼してください。既定では、それぞれが、アクセスパネルへのリンクが記載されたメールを Microsoft Entra ID から受け取り、そこでアプリケーションへのアクセスをレビューします。
レビューが開始したら、アクセスレビューが完了するまで、その進行状況を監視し、必要に応じて承認者を更新できます。その後、レビュー担当者によってアクセスを拒否されたユーザーのアクセス権が、アプリケーションから削除されていることを確認できます。
レビューの作成時に自動適用を選ばなかった場合は、完了時にレビュー結果を適用する必要があります。
レビューの状態が [結果を適用済み] に変わるまで待ちます。拒否されたユーザーが存在する場合は、そのアプリケーションロールの割り当てが数分以内に削除されることが予想されます。
結果が適用されると、Microsoft Entra ID は、アプリケーションから拒否されたユーザーのプロビジョニング解除を開始します。ユーザーのプロビジョニングにかかる時間のガイダンスに基づいて、Microsoft Entra プロビジョニングが拒否されたユーザーのプロビジョニング解除を開始するまで待ちます。ポータルまたは Graph API を使ってプロビジョニングの状態を監視し、拒否されたすべてのユーザーが正常に削除されたことを確認します。

プロビジョニングを解除されたユーザーが表示されない場合は、ユーザーがプロビジョニングされていない問題に関するトラブルシューティングガイドを確認してください。プロビジョニング状態にエラーが表示され、オンプレミスアプリケーションにプロビジョニングしている場合は、オンプレミスアプリケーションのプロビジョニングに関するトラブルシューティングガイドを確認してください。

既存のアクセスが確認されたことを確認するベースラインが作成されたので、次のセクションでエンタイトルメント管理を構成し、新しいアクセス要求を有効にすることができます。

エンタイトルメント管理を使用してアクセスを管理する

アプリケーションロールごとに異なるレビュー担当者を指定する場合、アプリケーションが複数のサービスプリンシパルによって表される場合、またはユーザーがアプリケーションへのアクセスを要求する、または割り当てを受けるプロセスを用意する場合など、その他の状況では、アプリケーションロールごとにアクセスパッケージで Microsoft Entra ID を構成することができます。各アクセスパッケージには、そのアクセスパッケージに対して行われる割り当ての定期的なレビューのポリシーを設定することができます。アクセスパッケージとポリシーを作成したら、既存のアプリケーションロールの割り当てを持つユーザーをアクセスパッケージに割り当てて、アクセスパッケージを介して割り当てを確認できるようにします。

このセクションでは、アプリロールの割り当てを含むアクセスパッケージの割り当てのレビュー用に Microsoft Entra エンタイトルメント管理を構成し、ユーザーがアプリケーションのロールへのアクセスを要求できるように追加のポリシーを構成します。

この手順では、Global administrator または Identity Governance administrator ロールであるか、カタログ作成者およびアプリケーションの所有者として委任されている必要があります。
アプリケーションガバナンスシナリオのカタログがまだない場合は、Microsoft Entra エンタイトルメント管理で [カタログの作成] を行ってください。 PowerShell スクリプトを使用して、各カタログを作成できます。
カタログに必要なリソースを設定するには、アプリケーションと、アプリケーションが依存するすべての Microsoft Entra グループをそのカタログ内のリソースとして追加します。 PowerShell スクリプトを使用して各リソースをカタログに追加できます。
アプリケーションごとに、またそれらのアプリケーションのロールまたはグループごとに、そのロールまたはグループをリソースとして含むアクセスパッケージを作成します。これらのアクセスパッケージを構成するこの段階では、各アクセスパッケージの最初のアクセスパッケージ割り当てポリシーを直接割り当てのポリシーになるように構成し、管理者のみがそのポリシーに割り当てを作成できるようにします。既存のユーザーがいる場合は、アクセスレビュー要件を設定し、ユーザーが無期限にアクセスを保持しないようにします。多数のアクセスパッケージがある場合は、PowerShell スクリプトを使用して、カタログ内に各アクセスパッケージを作成できます。
アクセスパッケージごとに、その対応するロール内のアプリケーションの既存のユーザー、またはそのグループのメンバーをアクセスパッケージに割り当てます。 Microsoft Entra 管理センターを使用してアクセスパッケージに直接ユーザーを割り当てるか、Graph または PowerShell を使用して一括で割り当てることができます。
アクセスパッケージの割り当てポリシーでアクセスレビューを構成した場合は、アクセスレビューが開始されたら、レビュー担当者に入力を依頼します。既定では、それぞれが、アクセスパネルへのリンクが記載されたメールを Microsoft Entra ID から受け取り、そこでアクセスパッケージの割り当てをレビューします。レビューを完了したときに、拒否されたユーザーが存在する場合は、そのアプリケーションロールの割り当てが数分以内に削除されることが予想されます。その後、Microsoft Entra ID は、アプリケーションから拒否されたユーザーのプロビジョニング解除を開始します。ユーザーのプロビジョニングにかかる時間のガイダンスに基づいて、Microsoft Entra プロビジョニングが拒否されたユーザーのプロビジョニング解除を開始するまで待ちます。ポータルまたは Graph API を使ってプロビジョニングの状態を監視し、拒否されたすべてのユーザーが正常に削除されたことを確認します。
職務の分離要件がある場合は、互換性のないアクセスパッケージまたは既存のグループをアクセスパッケージ用に構成します。シナリオで職務の分離チェックをオーバーライドする機能が必要な場合は、それらのオーバーライドシナリオ用に追加のアクセスパッケージを設定することもできます。
まだアクセス権を持っていないユーザーがアクセスを要求できるようにする場合は、各アクセスパッケージで、ユーザーがアクセスを要求できるように追加のアクセスパッケージ割り当てポリシーを作成します。そのポリシーで、承認と定期的なアクセスレビューの要件を構成します。