次の方法で共有

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

  • [アーティクル]

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

ライセンス要件

この機能を使用するには、Microsoft Entra ID Governance または Microsoft Entra スイートのライセンスが必要です。 要件に適したライセンスを見つけるには、「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 に記録されるようにするための最初の手順は、アプリケーションにアクセスできる既存のユーザーのリストを収集することです。

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

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

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

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

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

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

  1. そのディレクトリ内のユーザーのうちのどれだけが、アプリケーションのユーザーとしてのスコープ内に存在するかを識別します。 この選択は、アプリケーションの構成によって異なります。 一部のアプリケーションでは、LDAP ディレクトリに存在するすべてのユーザーが有効なユーザーとなります。 他のアプリケーションでは、ユーザーが特定の属性を持っているか、またはそのディレクトリ内のグループのメンバーであることが必要な場合もあります。

  2. ディレクトリからそのユーザーのサブセットを取得するコマンドを実行します。 その出力には、Microsoft Entra ID との照合に使用されるユーザーの属性が必ず含まれるようにしてください。 これらの属性の例には、従業員 ID、アカウント名、電子メール アドレスなどがあります。

    たとえば、次のコマンドでは、LDAP ディレクトリ内のすべてのユーザーの userPrincipalName 属性を含む CSV ファイルを現在のファイル システム ディレクトリ内に生成します。

    $out_filename = ".\users.csv"
csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"

  3. 必要に応じて、ユーザーの一覧を含む CSV ファイルを Microsoft Graph PowerShell コマンドレットがインストールされているシステムに転送します。

  4. 引き続き、この記事の後の方にある「Microsoft Entra ID にアプリケーションのユーザーに一致するユーザーが存在することを確認する」セクションを参照してください。

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

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

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

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

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

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

  1. プロビジョニング エージェントがインストールされている、またはインストールする予定のシステムにログインします。

  2. PowerShell を開きます。

  3. データベース システムに接続するための接続文字列を構築します。

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

    別のデータベースを使用している場合は、そのデータベースに接続するための必須キーワードを含める必要があります。 たとえば、データベースで DSN ファイルの完全修飾パス名、ユーザー ID、パスワードを使用している場合は、次のコマンドを使用して接続文字列を作成します。

    $filedsn = "c:\users\administrator\documents\db.dsn"
$db_cs = "filedsn=" + $filedsn + ";uid=p;pwd=secret"

  4. 次のコマンドを使用して、データベースへの接続を開き、接続文字列を指定します。

    $db_conn = New-Object data.odbc.OdbcConnection
$db_conn.ConnectionString = $db_cs
$db_conn.Open()

  5. データベース テーブルからユーザーを取得する SQL クエリを作成します。 アプリケーションのデータベース内のユーザーを Microsoft Entra ID 内のユーザーと照合するために使用される列を必ず含めてください。 これらの列には、従業員 ID、アカウント名、電子メール アドレスなどが含まれることがあります。

    たとえば、ユーザーが列 name と email を含む USERS という名前のデータベース テーブル内に保持されている場合は、次のコマンドを入力します。

    $db_query = "SELECT name,email from USERS"

  6. このクエリを接続経由でデータベースに送信します。

    $result = (new-object data.odbc.OdbcCommand($db_query,$db_conn)).ExecuteReader()
$table = new-object System.Data.DataTable
$table.Load($result)

    その結果は、クエリから取得されたユーザーを表す行の一覧です。

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

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

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

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

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

  1. SAP Cloud Identity Services 管理コンソール、https://<tenantID>.accounts.ondemand.com/admin、または試用版の場合には https://<tenantID>.trial-accounts.ondemand.com/admin にサインインします。
  2. [ユーザーと認可] > [ユーザーのエクスポート] に移動します。
  3. Microsoft Entra ユーザーを SAP のユーザーと照合するために必要なすべての属性を選択します。 これには、SAP システムで使っている可能性のある SCIM ID、userName、emails、その他の属性が含まれます。
  4. [エクスポート] を選択し、ブラウザーが CSV ファイルをダウンロードするまで待ちます。
  5. このシステムに 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 ガバナンス管理者、アプリケーション ロールの割り当ての管理だけを行う場合。

  1. PowerShell を開きます。

  2. Microsoft Graph PowerShell モジュールがまだインストールされていない場合は、次のコマンドを使用して Microsoft.Graph.Users モジュールなどをインストールします。

    Install-Module Microsoft.Graph

    これらのモジュールが既にインストールされている場合は、最新バージョンを使用していることを確認します。

    Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications

  3. Microsoft Entra ID に接続します。

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

  4. このコマンドを初めて使用する場合は、Microsoft Graph コマンド ライン ツールにこれらのアクセス許可を付与することを許可する必要があります。

  5. アプリケーションのデータ ストアから取得したユーザーの一覧を、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

  6. 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"

  7. 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 }
}

  8. 前のクエリの結果を表示します。 エラーまたは一致が見つからないために、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."

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

    たとえば、ユーザーのメールアドレスと userPrincipalName が Microsoft Entra ID で変更されたのに、アプリケーションのデータ ソースでそれに対応する mail プロパティが更新されていない可能性があります。 または、ユーザーは既に組織を離れているが、まだアプリケーションのデータ ソースに存在する可能性があります。 あるいは、アプリケーションのデータ ソースに、Microsoft Entra ID 内のどの特定のユーザーにも対応していないベンダーまたはスーパー管理者アカウントが存在する可能性もあります。

  10. Microsoft Entra ID で見つけられなかったか、またはアクティブかつサインインできる状態でなかったユーザーが存在したが、そのアクセスをレビューしたり、その属性を SAP Cloud Identity Services、データベース、またはディレクトリで更新したい場合は、アプリケーションまたは照合ルールを更新するか、そのユーザー用の Microsoft Entra ユーザーを更新する必要があります。 どの変更を行うかの詳細については、「Microsoft Entra ID のユーザーと一致しなかったアプリケーションのマッピングとユーザー アカウントを管理する」を参照してください。

    Microsoft Entra ID でユーザーを作成するオプションを選択した場合、次のいずれかを使用してユーザーを一括で作成できます。

    これらの新しいユーザーに、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
   }
}

  11. 不足しているすべてのユーザーを 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 に登録されている場合は、次の手順に進みます。

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

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

  1. アプリケーションのサービス プリンシパルのサービス プリンシパル 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

  2. Microsoft Entra ID で現在アプリケーションに割り当てられているユーザーを取得します。

    これは前のコマンドで設定した $azuread_sp 変数に基づいています。

    $azuread_existing_assignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)

  3. 前のセクションのユーザー 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 人以上のユーザーが現在アプリケーション ロールに割り当てられていない場合は、手順を続行して、それらをいずれかのアプリケーションのロールに追加する必要があります。

  4. 残りのユーザーを割り当てるアプリケーション ロールを選択します。

    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 つ) が必要になることがあります。 アプリケーションがプロビジョニングをサポートしていない場合は、次のセクションに進んでください。

  1. 選択したユーザーのみがアプリケーションにプロビジョニングされるよう、ユーザーにアプリケーション ロールの割り当てを要求するようにアプリケーションが構成されていることを確認します。

  2. アプリケーションへのプロビジョニングが構成されていない場合は、それをここで構成します (ただし、またプロビジョニングは開始しません)。

  3. アプリケーションの [プロパティ] タブを選択します。 [ユーザーの割り当てが必要ですか?] オプションが [はい] に設定されていることを確認します。 [いいえ] に設定されている場合は、外部 ID を含むディレクトリ内のすべてのユーザーがアプリケーションにアクセスでき、アプリケーションへのアクセスをレビューすることはできません。

  4. そのアプリケーションへのプロビジョニングの属性マッピングを確認します。 照合のために前のセクションで使用した Microsoft Entra の属性と列に対して [この属性を使用してオブジェクトを照合する] が設定されていることを確認します。

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

  5. アプリケーションの属性に isSoftDeleted の属性マッピングがあることを確認します。

    ユーザーがアプリケーションから割り当て解除されるか、Microsoft Entra ID で論理的に削除されるか、またはサインインからブロックされると、Microsoft Entra プロビジョニングでは isSoftDeleted にマップされた属性が更新されます。 マップされた属性がない場合、後でアプリケーション ロールから割り当て解除されたユーザーは、引き続きアプリケーションのデータ ストアに存在します。

  6. アプリケーションのプロビジョニングが既に有効になっている場合は、アプリケーションのプロビジョニングが検疫状態になっていないことを確認します。 先に進む前に、検疫の原因となっている問題をすべて解決します。

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 からアプリケーションにサインインできなくなります。

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

    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 
}

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

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

  1. Microsoft Entra ID にクエリを実行して、ロールの割り当ての更新された一覧を取得します。

    $azuread_existing_assignments = @(Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $azuread_sp.Id -All)

  2. 前のセクションのユーザー 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 監査ログで前のステップのエラーを確認します。

  3. アプリケーション サービス プリンシパルがプロビジョニング用に構成されており、サービス プリンシパルの [プロビジョニング状態] が [オフ] の場合は、それを [オン] にします。 Graph API を使ってプロビジョニングを開始することもできます。

  4. 「ユーザーをプロビジョニングするにはどのくらいの時間がかかりますか」というガイダンスに基づき、Microsoft Entra プロビジョニングによって、アプリケーションの既存のユーザーと割り当てられたばかりのユーザーが照合されるのを待ちます。

  5. ポータルまたは Graph API を使ってプロビジョニングの状態を監視し、すべてのユーザーが正常に一致したことを確認します。

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

  6. 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 へのサインインをブロックされている場合は、レビューを実行できません。

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

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

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

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

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

  1. この手順では、全体管理者または ID ガバナンス管理者ロールに属している必要があります。

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

    Note

    アクセス レビューの作成時にレビュー判断ヘルパーを有効にした場合、ユーザーが Microsoft Entra ID を使用してアプリケーションに最後にサインインした日時に応じて、判断ヘルパーの推奨事項は 30 日間の間隔に基づいて決まります。

  3. アクセス レビューの開始時には、レビュー担当者に入力するよう依頼してください。 既定では、それぞれが、アクセス パネルへのリンクが記載されたメールを Microsoft Entra ID から受け取り、そこでアプリケーションへのアクセスをレビューします。

  4. レビューが開始したら、アクセス レビューが完了するまで、その進行状況を監視し、必要に応じて承認者を更新できます。 その後、レビュー担当者によってアクセスを拒否されたユーザーのアクセス権が、アプリケーションから削除されていることを確認できます。

  5. レビューの作成時に自動適用を選ばなかった場合は、完了時にレビュー結果を適用する必要があります。

  6. レビューの状態が [結果を適用済み] に変わるまで待ちます。 拒否されたユーザーが存在する場合は、そのアプリケーション ロールの割り当てが数分以内に削除されることが予想されます。

  7. 結果が適用されると、Microsoft Entra ID は、アプリケーションから拒否されたユーザーのプロビジョニング解除を開始します。 ユーザーのプロビジョニングにかかる時間のガイダンスに基づいて、Microsoft Entra プロビジョニングが拒否されたユーザーのプロビジョニング解除を開始するまで待ちます。 ポータルまたは Graph API を使ってプロビジョニングの状態を監視し、拒否されたすべてのユーザーが正常に削除されたことを確認します。

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

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

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

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

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

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

次のステップ