Condividi tramite

Gestire gli utenti esistenti di un'applicazione - Microsoft PowerShell

  • Articolo

Esistono tre scenari comuni in cui è necessario popolare l'ID Microsoft Entra con gli utenti esistenti di un'applicazione prima di usare l'applicazione con una funzionalità di governance dell'ID di Microsoft Entra, ad esempio le verifiche di accesso.

Requisiti di licenza

L'uso di questa funzionalità richiede le licenze di Microsoft Entra ID Governance o della Famiglia di prodotti Microsoft Entra. Per trovare la licenza appropriata per i requisiti, vedere Nozioni fondamentali sulle licenze di Microsoft Entra ID Governance.

Applicazione migrata all'ID Microsoft Entra dopo aver usato il proprio provider di identità

Nel primo scenario, l'applicazione esiste già nell'ambiente. In precedenza, l'applicazione usava il proprio provider di identità o archivio dati per tenere traccia degli utenti a cui era stato eseguito l'accesso.

Quando si modifica l'applicazione in modo che si basi sull'ID Microsoft Entra, solo gli utenti che si trovano nell'ID Microsoft Entra e possono accedere a tale applicazione. Come parte di tale modifica di configurazione, è possibile scegliere di inserire gli utenti esistenti dall'archivio dati dell'applicazione nell'ID Microsoft Entra. Tali utenti continuano quindi ad avere accesso tramite Microsoft Entra ID.

La presenza di utenti associati all'applicazione rappresentata in Microsoft Entra ID consentirà a Microsoft Entra ID di tenere traccia degli utenti che hanno accesso all'applicazione, anche se la relazione con l'applicazione ha avuto origine altrove. Ad esempio, la relazione potrebbe avere avuto origine nel database o nella directory di un'applicazione.

Dopo che Microsoft Entra ID è a conoscenza dell'assegnazione di un utente, può inviare aggiornamenti all'archivio dati dell'applicazione. Gli aggiornamenti includono quando gli attributi dell'utente cambiano o quando l'utente esce dall'ambito dell'applicazione.

Applicazione che non usa Microsoft Entra ID come unico provider di identità

Nel secondo scenario, un'applicazione non si basa esclusivamente sull'ID Microsoft Entra come provider di identità.

In alcuni casi, un'applicazione potrebbe basarsi su gruppi di Active Directory. Questo scenario è descritto in Modello B in Preparazione per una verifica di accesso dell'accesso degli utenti a un'applicazione. Non è necessario configurare il provisioning per l'applicazione, come descritto in tale articolo, seguire invece le istruzioni per il modello B in tale articolo su come esaminare l'appartenenza ai gruppi di Active Directory.

In altri casi, un'applicazione potrebbe supportare più provider di identità o avere una propria risorsa di archiviazione delle credenziali predefinita. Questo scenario è descritto come Modello C in Preparazione per una verifica di accesso dell'accesso degli utenti a un'applicazione.

Potrebbe non essere possibile rimuovere altri provider di identità o l'autenticazione delle credenziali locali dall'applicazione. In tal caso, se si vuole usare Microsoft Entra ID per verificare chi ha accesso a tale applicazione o rimuovere l'accesso di un utente da tale applicazione, sarà necessario creare assegnazioni in Microsoft Entra ID che rappresentano gli utenti dell'applicazione che non si basano su Microsoft Entra ID per l'autenticazione.

La presenza di queste assegnazioni è necessaria se si prevede di esaminare tutti gli utenti con accesso all'applicazione, come parte di una verifica di accesso.

Si supponga, ad esempio, che un utente si trova nell'archivio dati dell'applicazione. Microsoft Entra ID è configurato per richiedere assegnazioni di ruolo all'applicazione. Tuttavia, l'utente non ha un'assegnazione di ruolo applicazione in Microsoft Entra ID.

Se l'utente viene aggiornato in Microsoft Entra ID, nessuna modifica verrà inviata all'applicazione. E se le assegnazioni di ruolo dell'applicazione vengono esaminate, l'utente non verrà incluso nella revisione. Per avere tutti gli utenti inclusi nella revisione, è necessario avere assegnazioni di ruolo dell'applicazione per tutti gli utenti dell'applicazione.

L'applicazione non usa Microsoft Entra ID come provider di identità né supporta il provisioning

Per alcune applicazioni legacy potrebbe non essere possibile rimuovere altri provider di identità o l'autenticazione delle credenziali locali dall'applicazione o abilitare il supporto per i protocolli di provisioning per tali applicazioni.

Questo scenario di un'applicazione che non supporta i protocolli di provisioning è trattato in un articolo separato, Gestire gli utenti esistenti di un'applicazione che non supporta il provisioning.

Terminologia

Questo articolo illustra il processo di gestione delle assegnazioni di ruolo dell'applicazione usando i cmdlet di PowerShell di Microsoft Graph. Usa la terminologia di Microsoft Graph seguente.

Diagramma che illustra la terminologia di Microsoft Graph.

In Microsoft Entra ID, un'entità servizio (ServicePrincipal) rappresenta un'applicazione nella directory di una determinata organizzazione. ServicePrincipal dispone di una proprietà denominata AppRoles che elenca i ruoli supportati da un'applicazione, ad esempio Marketing specialist. AppRoleAssignment collega un utente a un'entità servizio e specifica il ruolo che l'utente ha in tale applicazione. Un'applicazione può avere più di un'entità servizio, se l'accesso Single Sign-On all'applicazione e il provisioning all'applicazione vengono gestiti separatamente.

È anche possibile usare i pacchetti di accesso alla gestione entitlement di Microsoft Entra per concedere agli utenti l'accesso limitato al tempo all'applicazione. Nella gestione AccessPackage entitlement, contiene uno o più ruoli delle risorse, potenzialmente da più entità servizio. AccessPackage include anche assegnazioni (Assignment) per gli utenti al pacchetto di accesso.

Quando si crea un'assegnazione per un utente a un pacchetto di accesso, la gestione entitlement di Microsoft Entra crea automaticamente le istanze necessarie AppRoleAssignment per l'utente all'entità servizio di ogni applicazione nel pacchetto di accesso. Per altre informazioni, vedere l'esercitazione Gestire l'accesso alle risorse nella gestione entitlement di Microsoft Entra su come creare pacchetti di accesso tramite PowerShell.

Operazioni preliminari

Raccogliere utenti esistenti da un'applicazione

Il primo passo per garantire che tutti gli utenti vengano registrati in Microsoft Entra ID consiste nel raccogliere l'elenco degli utenti esistenti che hanno accesso all'applicazione.

Alcune applicazioni potrebbero avere un comando predefinito per esportare un elenco di utenti correnti dall'archivio dati. In altri casi, l'applicazione potrebbe basarsi su una directory o un database esterno.

In alcuni ambienti, l'applicazione potrebbe trovarsi in un segmento di rete o in un sistema non appropriato per la gestione dell'accesso a Microsoft Entra ID. Potrebbe quindi essere necessario estrarre l'elenco di utenti da tale directory o database e quindi trasferirlo come file in un altro sistema che può essere usato per le interazioni con Microsoft Entra.

Questa sezione illustra quattro approcci per ottenere un elenco di utenti in un file con valori delimitati da virgole (CSV):

  • Da una directory LDAP
  • Da un database di SQL Server
  • Da un altro database basato su SQL
  • Da SAP Cloud Identity Services

Raccogliere utenti esistenti da un'applicazione che usa una directory LDAP

Questa sezione si applica alle applicazioni che usano una directory LDAP come archivio dati sottostante per gli utenti che non eseguono l'autenticazione con Microsoft Entra ID. Molte directory LDAP, ad esempio Active Directory, includono un comando che restituisce un elenco di utenti.

  1. Identificare quali utenti di tale directory rientrano nell'ambito per essere utenti dell'applicazione. Questa scelta dipenderà dalla configurazione dell'applicazione. Per alcune applicazioni, qualsiasi utente presente in una directory LDAP è un utente valido. Per altre applicazioni potrebbe essere necessario che l'utente disponga di un attributo specifico o di un membro di un gruppo in tale directory.

  2. Eseguire il comando che recupera il subset di utenti dalla directory. Assicurarsi che l'output includa gli attributi degli utenti che verranno usati per la corrispondenza con Microsoft Entra ID. Esempi di questi attributi sono ID dipendente, nome account e indirizzo di posta elettronica.

    Ad esempio, questo comando genera un file CSV nella directory del file system corrente con l'attributo userPrincipalName di ogni persona nella directory LDAP:

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

  3. Se necessario, trasferire il file CSV che contiene l'elenco di utenti in un sistema con i cmdlet di PowerShell di Microsoft Graph installati.

  4. Continuare a leggere nella sezione Confermare che l'ID Microsoft Entra abbia utenti che corrispondono agli utenti della sezione dell'applicazione più avanti in questo articolo.

Raccogliere utenti esistenti dalla tabella di database di un'applicazione tramite una procedura guidata di SQL Server

Questa sezione si applica alle applicazioni che usano SQL Server come archivio dati sottostante.

Prima di tutto, ottenere un elenco degli utenti dalle tabelle. La maggior parte dei database consente di esportare il contenuto delle tabelle in un formato di file standard, ad esempio in un file CSV. Se l'applicazione usa un database di SQL Server, è possibile usare l'Importazione/Esportazione guidata SQL Server per esportare parti di un database. Se non si dispone di un'utilità per il database, è possibile usare il driver ODBC con PowerShell, come descritto nella sezione successiva.

  1. Accedere al sistema in cui è installato SQL Server.
  2. Aprire SQL Server 2019 Import and Export (64 bit) o l'equivalente per il database.
  3. Selezionare il database esistente come origine.
  4. Selezionare Destinazione file flat come destinazione. Specificare un nome file e modificare il valore della tabella codici impostando 65001 (UTF-8).
  5. Completare la procedura guidata e selezionare l'opzione per l'esecuzione immediata.
  6. Attendere il completamento dell'esecuzione.
  7. Se necessario, trasferire il file CSV che contiene l'elenco di utenti in un sistema con i cmdlet di PowerShell di Microsoft Graph installati.
  8. Continuare a leggere nella sezione Confermare che l'ID Microsoft Entra abbia utenti che corrispondono agli utenti della sezione dell'applicazione più avanti in questo articolo.

Raccogliere utenti esistenti dalla tabella di database di un'applicazione usando PowerShell

Questa sezione si applica alle applicazioni che usano un altro database SQL come archivio dati sottostante, in cui si usa l'host del connettore ECMA per effettuare il provisioning degli utenti in tale applicazione. Se l'agente di provisioning non è ancora stato configurato, usare questa guida per creare il file di connessione DSN che verrà usato in questa sezione.

  1. Accedere al sistema in cui è o verrà installato l'agente di provisioning.

  2. Aprire PowerShell.

  3. Creare un stringa di connessione per la connessione al sistema di database.

    I componenti di un stringa di connessione dipendono dai requisiti del database. Se si usa SQL Server, vedere l'elenco di parole chiave e attributi DSN e stringa di connessione.

    Se si usa un database diverso, è necessario includere le parole chiave obbligatorie per la connessione a tale database. Ad esempio, se il database usa il nome completo del percorso del file DSN, un ID utente e una password, costruire il stringa di connessione usando i comandi seguenti:

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

  4. Aprire una connessione al database e fornire il stringa di connessione usando i comandi seguenti:

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

  5. Creare una query SQL per recuperare gli utenti dalla tabella di database. Assicurarsi di includere le colonne che verranno usate per associare gli utenti nel database dell'applicazione con gli utenti in Microsoft Entra ID. Le colonne possono includere l'ID dipendente, il nome dell'account o l'indirizzo di posta elettronica.

    Ad esempio, se gli utenti si trovano in una tabella di database denominata USERS con colonne name e email, immettere il comando seguente:

    $db_query = "SELECT name,email from USERS"

  6. Inviare la query al database tramite la connessione:

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

    Il risultato è l'elenco di righe che rappresenta gli utenti recuperati dalla query.

  7. Scrivere il risultato in un file CSV:

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

  8. Se il sistema non dispone dei cmdlet di Microsoft Graph PowerShell installati o non dispone della connettività all'ID Microsoft Entra, trasferire il file CSV che contiene l'elenco di utenti a un sistema in cui sono installati i cmdlet di Microsoft Graph PowerShell.

Raccogliere utenti esistenti da SAP Cloud Identity Services

Questa sezione si applica alle applicazioni SAP che usano SAP Cloud Identity Services come servizio sottostante per il provisioning utenti.

  1. Accedere alla console https://<tenantID>.accounts.ondemand.com/admin di amministrazione di SAP Cloud Identity Services o https://<tenantID>.trial-accounts.ondemand.com/admin in caso di versione di valutazione.
  2. Passare a Utenti e autorizzazioni > Esporta utenti.
  3. Selezionare tutti gli attributi necessari per associare gli utenti di Microsoft Entra a quelli in SAP. Sono inclusi gli SCIM IDattributi , userName, emailse altri che è possibile usare nei sistemi SAP.
  4. Selezionare Esporta e attendere che il browser scarichi il file CSV.
  5. Se il sistema non dispone dei cmdlet di Microsoft Graph PowerShell installati o non dispone della connettività all'ID Microsoft Entra, trasferire il file CSV che contiene l'elenco di utenti a un sistema in cui sono installati i cmdlet di Microsoft Graph PowerShell.

Verificare che Microsoft Entra ID abbia utenti che corrispondono agli utenti dell'applicazione

Ora che si dispone di un elenco di tutti gli utenti ottenuti dall'applicazione, sarà possibile associare gli utenti dall'archivio dati dell'applicazione con gli utenti in Microsoft Entra ID.

Prima di procedere, esaminare le informazioni sugli utenti corrispondenti nei sistemi di origine e di destinazione. Successivamente si configurerà il provisioning di Microsoft Entra con mapping equivalenti. Questo passaggio consentirà al provisioning di Microsoft Entra di eseguire query sull'archivio dati dell'applicazione con le stesse regole di corrispondenza.

Recuperare gli ID degli utenti in Microsoft Entra ID

Questa sezione illustra come interagire con Microsoft Entra ID usando i cmdlet di Microsoft Graph PowerShell.

La prima volta che l'organizzazione usa questi cmdlet per questo scenario, è necessario avere il un ruolo di amministratore globale per consentire l'uso di Microsoft Graph PowerShell nel tenant. Le interazioni successive possono usare un ruolo con privilegi inferiori, ad esempio:

  • Amministratore utenti, se si prevede di creare nuovi utenti.
  • Amministratore dell'applicazione o Amministratore della governance delle identità, se si gestiscono solo le assegnazioni di ruolo dell'applicazione.

  1. Aprire PowerShell.

  2. Se non sono già installati i moduli di Microsoft Graph PowerShell, installare il modulo Microsoft.Graph.Users e altri usando questo comando:

    Install-Module Microsoft.Graph

    Se i moduli sono già installati, assicurarsi di usare una versione recente:

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

  3. Connettersi a Microsoft Entra ID:

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

  4. Se è la prima volta che è stato usato questo comando, potrebbe essere necessario fornire il consenso per permettere agli strumenti della riga di comando di Microsoft Graph di avere queste autorizzazioni.

  5. Leggere l'elenco degli utenti ottenuti dall'archivio dati dell'applicazione nella sessione di PowerShell. Se l'elenco degli utenti si trovava in un file CSV, è possibile usare il cmdlet Import-Csv di PowerShell e specificare il nome del file della sezione precedente come argomento.

    Ad esempio, se il file ottenuto da SAP Cloud Identity Services è denominato Users-exported-from-sap.csv e si trova nella directory corrente, immettere questo comando.

    $filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8

    Per un altro esempio se si usa un database o una directory, se il file è denominato users.csv e si trova nella directory corrente, immettere questo comando:

    $filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8

  6. Scegliere la colonna del file users.csv che corrisponderà a un attributo di un utente in Microsoft Entra ID.

    Se si usa SAP Cloud Identity Services, il mapping predefinito è l'attributo userName SAP SCIM con l'attributo userPrincipalNameMICROSOFT Entra ID :

    $db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"

    Per un altro esempio se si usa un database o una directory, è possibile che siano presenti utenti in un database in cui il valore nella colonna denominata EMail è lo stesso valore dell'attributo userPrincipalNameMicrosoft Entra :

    $db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"

  7. Recuperare gli ID di tali utenti in Microsoft Entra ID.

    Lo script di PowerShell seguente usa i $dbusersvalori , $db_match_column_namee $azuread_match_attr_name specificati in precedenza. Eseguirà una query su Microsoft Entra ID per individuare un utente con un attributo con un valore corrispondente per ogni record nel file di origine. Se sono presenti molti utenti nel file ottenuto dall'origine SAP Cloud Identity Services, dal database o dalla directory, il completamento di questo script potrebbe richiedere alcuni minuti. Se non si dispone di un attributo in Microsoft Entra ID che ha il valore e che deve usare un'espressione contains di filtro o un'altra, sarà necessario personalizzare questo script e che nel passaggio 11 riportato di seguito per usare un'espressione di filtro diversa.

    $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. Visualizzare i risultati delle query precedenti. Verificare se uno degli utenti in SAP Cloud Identity Services, il database o la directory non è stato possibile trovare in Microsoft Entra ID, a causa di errori o corrispondenze mancanti.

    Lo script di PowerShell seguente visualizzerà i conteggi dei record che non si trovano:

    $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. Al termine dello script, indicherà un errore se eventuali record dell'origine dati non si trovano in Microsoft Entra ID. Se non tutti i record per gli utenti dell'archivio dati dell'applicazione potrebbero trovarsi come utenti in Microsoft Entra ID, è necessario analizzare quali record non corrispondono e perché.

    Ad esempio, l'indirizzo di posta elettronica di un utente e userPrincipalName potrebbe essere stato modificato nell'ID Microsoft Entra senza aggiornare la proprietà corrispondente mail nell'origine dati dell'applicazione. In alternativa, l'utente potrebbe aver già lasciato l'organizzazione, ma si trova ancora nell'origine dati dell'applicazione. In alternativa, potrebbe essere presente un account fornitore o amministratore con privilegi avanzati nell'origine dati dell'applicazione che non corrisponde a una persona specifica nell'ID Microsoft Entra.

  10. Se sono presenti utenti che non potevano trovarsi in Microsoft Entra ID o non erano attivi e non sono stati in grado di accedere, ma si vuole avere l'accesso esaminato o i relativi attributi aggiornati in SAP Cloud Identity Services, nel database o nella directory, è necessario aggiornare l'applicazione, la regola di corrispondenza o aggiornare o creare utenti di Microsoft Entra per loro. Per altre informazioni sulle modifiche da apportare, vedere Gestire mapping e account utente nelle applicazioni che non corrispondono agli utenti in Microsoft Entra ID.

    Se si sceglie l'opzione di creazione di utenti in Microsoft Entra ID, è possibile creare utenti in blocco usando uno dei due elementi seguenti:

    Assicurarsi che questi nuovi utenti siano popolati con gli attributi necessari per Microsoft Entra ID per associarli in un secondo momento agli utenti esistenti nell'applicazione e gli attributi richiesti dall'ID Microsoft Entra, inclusi userPrincipalName, mailNickname e displayName. Il valore di userPrincipalName deve essere univoco tra tutti gli utenti nella directory.

    Ad esempio, in un database potrebbero essere presenti utenti per cui il valore nella colonna denominata EMail è il valore che si vuole usare come nome dell'entità utente Microsoft Entra, il valore nella colonna Alias contiene il nome alternativo di posta elettronica di Microsoft Entra ID e il valore nella colonna Full name contiene il nome visualizzato dell'utente:

    $db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"

    È quindi possibile usare questo script per creare utenti di Microsoft Entra per quelli in SAP Cloud Identity Services, nel database o nella directory che non corrispondono agli utenti in Microsoft Entra ID. Si noti che potrebbe essere necessario modificare questo script per aggiungere altri attributi di Microsoft Entra necessari nell'organizzazione o se non è né mailNickname userPrincipalName, per fornire l'attributo $azuread_match_attr_name 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. Dopo aver aggiunto gli utenti mancanti all'ID Microsoft Entra, eseguire di nuovo lo script del passaggio 7. Eseguire quindi lo script dal passaggio 8. Verificare che non vengano segnalati errori.

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

Registrare l'applicazione

Se l'applicazione è già registrata in Microsoft Entra ID, continuare con il passaggio successivo.

Verificare la presenza di utenti non già assegnati all'applicazione

I passaggi precedenti hanno confermato che tutti gli utenti nell'archivio dati dell'applicazione esistono come utenti in Microsoft Entra ID. Tuttavia, potrebbero non essere tutti attualmente assegnati ai ruoli dell'applicazione in Microsoft Entra ID. I passaggi successivi sono quindi vedere quali utenti non hanno assegnazioni ai ruoli dell'applicazione.

  1. Cercare l'ID entità servizio per l'entità servizio dell'applicazione. Se di recente è stata creata un'entità servizio per un'applicazione che usa una directory LDAP o un database SQL, usare il nome dell'entità servizio.

    Ad esempio, se l'applicazione aziendale è denominata CORPDB1, immettere i comandi seguenti:

    $azuread_app_name = "CORPDB1"
$azuread_sp_filter = "displayName eq '" + ($azuread_app_name -replace "'","''") + "'"
$azuread_sp = Get-MgServicePrincipal -Filter $azuread_sp_filter -All

  2. Recuperare gli utenti che hanno attualmente assegnazioni all'applicazione in Microsoft Entra ID.

    Questo si basa sulla $azuread_sp variabile impostata nel comando precedente.

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

  3. Confrontare l'elenco di ID utente della sezione precedente con gli utenti attualmente assegnati all'applicazione:

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

    Se zero utenti non sono assegnati ai ruoli applicazione, a indicare che tutti gli utenti vengono assegnati ai ruoli applicazione, non è necessario apportare altre modifiche prima di eseguire una verifica di accesso.

    Tuttavia, se uno o più utenti non sono attualmente assegnati ai ruoli dell'applicazione, è necessario continuare la procedura e aggiungerli a uno dei ruoli dell'applicazione.

  4. Selezionare il ruolo dell'applicazione a cui assegnare gli utenti rimanenti.

    Un'applicazione potrebbe avere più di un ruolo e un'entità servizio può avere ruoli aggiuntivi. Usare questo comando per elencare i ruoli disponibili di un'entità servizio:

    $azuread_sp.AppRoles | where-object {$_.AllowedMemberTypes -contains "User"} | ft DisplayName,Id

    Selezionare il ruolo appropriato dall'elenco e ottenere il relativo ID ruolo. Ad esempio, se il nome del ruolo è Admin, specificare tale valore nei comandi di PowerShell seguenti:

    $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"}

Configurare il provisioning delle applicazioni

Se l'applicazione usa una directory LDAP, un database SQL, SAP Cloud Identity Services o supporta SCIM, prima di creare nuove assegnazioni, configurare il provisioning degli utenti di Microsoft Entra nell'applicazione. La configurazione del provisioning prima della creazione delle assegnazioni consentirà a Microsoft Entra ID di associare gli utenti in Microsoft Entra ID con le assegnazioni di ruolo dell'applicazione agli utenti già presenti nell'archivio dati dell'applicazione. Se l'applicazione ha una directory o un database locale di cui eseguire il provisioning e supporta anche l'accesso SSO federato, potrebbero essere necessarie due entità servizio per rappresentare l'applicazione nella directory: una per il provisioning e una per l'accesso SSO. Se l'applicazione non supporta il provisioning, continuare la lettura nella sezione successiva.

  1. Assicurarsi che l'applicazione sia configurata per richiedere agli utenti di avere assegnazioni di ruolo dell'applicazione, in modo che venga effettuato il provisioning solo degli utenti selezionati nell'applicazione.

  2. Se il provisioning non è stato configurato per l'applicazione, configurarlo ora (ma non avviare il provisioning):

  3. Controllare la scheda Proprietà per l'applicazione. Verificare che l'opzione Assegnazione utente obbligatoria? sia impostata su Sì. Se è impostata su No, tutti gli utenti nella directory, incluse le identità esterne, possono accedere all'applicazione e non è possibile esaminare l'accesso all'applicazione.

  4. Controllare i mapping degli attributi per il provisioning in tale applicazione. Assicurarsi che gli oggetti Match che usano questo attributo siano impostati per l'attributo e la colonna Microsoft Entra usati nelle sezioni precedenti per la corrispondenza.

    Se queste regole non usano gli stessi attributi usati in precedenza, quando vengono create assegnazioni di ruolo dell'applicazione, l'ID Microsoft Entra potrebbe non essere in grado di individuare gli utenti esistenti nell'archivio dati dell'applicazione. Microsoft Entra ID potrebbe quindi creare inavvertitamente utenti duplicati.

  5. Verificare che sia presente un mapping degli attributi per isSoftDeleted a un attributo dell'applicazione.

    Quando un utente non viene assegnato dall'applicazione, eliminato soft-delete in Microsoft Entra ID o bloccato dall'accesso, il provisioning di Microsoft Entra aggiornerà l'attributo mappato a isSoftDeleted. Se non viene eseguito il mapping di alcun attributo, gli utenti che in seguito non vengono assegnati dal ruolo applicazione continueranno a esistere nell'archivio dati dell'applicazione.

  6. Se il provisioning è già stato abilitato per l'applicazione, verificare che il provisioning dell'applicazione non sia in quarantena. Risolvere eventuali problemi che causano la quarantena prima di procedere.

Creare assegnazioni di ruolo dell'app in Microsoft Entra ID

Affinché Microsoft Entra ID corrisponda agli utenti nell'applicazione con gli utenti in Microsoft Entra ID, è necessario creare assegnazioni di ruolo dell'applicazione in Microsoft Entra ID. Ogni assegnazione di ruolo applicazione associa un utente a un ruolo applicazione di un'entità servizio.

Quando viene creata un'assegnazione di ruolo applicazione in Microsoft Entra ID per un utente a un'applicazione e l'applicazione supporta il provisioning, quindi:

  • Microsoft Entra ID eseguirà una query sull'applicazione tramite SCIM, o la relativa directory o database, per determinare se l'utente esiste già.
  • Quando vengono eseguiti aggiornamenti successivi agli attributi dell'utente in Microsoft Entra ID, Microsoft Entra ID invierà tali aggiornamenti all'applicazione.
  • L'utente rimarrà all'interno dell'applicazione per un periodo illimitato, a meno che non venga aggiornato all'esterno dell'ID Microsoft Entra o fino a quando non viene rimossa l'assegnazione in Microsoft Entra ID.
  • Nella verifica di accesso successiva delle assegnazioni di ruolo dell'applicazione, l'utente verrà incluso nella verifica di accesso.
  • Se l'utente viene negato in una verifica di accesso, l'assegnazione di ruolo dell'applicazione verrà rimossa. Microsoft Entra ID informerà l'applicazione che l'utente è bloccato dall'accesso.

Se l'applicazione non supporta il provisioning,

  • L'utente rimarrà all'interno dell'applicazione per un periodo illimitato, a meno che non venga aggiornato all'esterno dell'ID Microsoft Entra o fino a quando non viene rimossa l'assegnazione in Microsoft Entra ID.
  • Nella revisione successiva delle assegnazioni di ruolo dell'applicazione, l'utente verrà incluso nella revisione.
  • Se l'utente viene negato in una verifica di accesso, l'assegnazione di ruolo dell'applicazione verrà rimossa. L'utente non sarà più in grado di accedere da Microsoft Entra ID all'applicazione.

  1. Creare assegnazioni di ruolo dell'applicazione per gli utenti che non dispongono attualmente di assegnazioni di ruolo:

    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. Attendere un minuto per la propagazione delle modifiche all'interno di Microsoft Entra ID.

Verificare che il provisioning di Microsoft Entra corrisponda agli utenti esistenti

  1. Eseguire una query sull'ID Microsoft Entra per ottenere l'elenco aggiornato delle assegnazioni di ruolo:

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

  2. Confrontare l'elenco di ID utente della sezione precedente con gli utenti ora assegnati all'applicazione:

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

    Se gli utenti non sono assegnati ai ruoli dell'applicazione, controllare il log di controllo di Microsoft Entra per un errore di un passaggio precedente.

  3. Se l'entità servizio dell'applicazione è configurata per il provisioning e lo stato del provisioning per l'entità servizio è Disattivato, attivarlo. È anche possibile avviare il provisioning usando le API Graph.

  4. In base alle indicazioni per quanto tempo sarà necessario effettuare il provisioning degli utenti, attendere che il provisioning di Microsoft Entra corrisponda agli utenti esistenti dell'applicazione a tali utenti appena assegnati.

  5. Monitorare lo stato del provisioning tramite il portale o le API Graph per assicurarsi che tutti gli utenti siano stati confrontati correttamente.

    Se non viene visualizzato il provisioning degli utenti, vedere la guida alla risoluzione dei problemi per nessun utente di cui viene effettuato il provisioning. Se viene visualizzato un errore nello stato di provisioning e si esegue il provisioning in un'applicazione locale, vedere la guida alla risoluzione dei problemi per il provisioning di applicazioni locali.

  6. Controllare il log di provisioning tramite l'interfaccia di amministrazione di Microsoft Entra o API Graph. Filtrare il log in base allo stato Errore. Se si verificano errori con errorCode of DuplicateTargetEntries, indica un'ambiguità nelle regole di corrispondenza del provisioning e sarà necessario aggiornare gli utenti di Microsoft Entra o i mapping usati per la corrispondenza per garantire che ogni utente di Microsoft Entra corrisponda a un utente dell'applicazione. Filtrare quindi il log con l'azione Crea e stato Ignorato. Se gli utenti sono stati ignorati con il codice SkipReason di NotEffectivelyEntitled, questo potrebbe indicare che gli account utente in Microsoft Entra ID non sono stati confrontati perché lo stato dell'account utente era Disabilitato.

Dopo che il servizio di provisioning Di Microsoft Entra corrisponde agli utenti in base alle assegnazioni di ruolo dell'applicazione create, le successive modifiche apportate a tali utenti verranno inviate all'applicazione.

Selezionare i revisori appropriati

Quando si crea ogni verifica di accesso, gli amministratori possono scegliere uno o più revisori. I revisori possono eseguire una verifica scegliendo gli utenti per l'accesso continuo a una risorsa o rimuovendoli.

In genere un proprietario della risorsa è responsabile dell'esecuzione di una revisione. Se si sta creando una revisione di un gruppo, come parte della revisione dell'accesso per un'applicazione integrata nel modello B, è possibile selezionare i proprietari del gruppo come revisori. Poiché le applicazioni in Microsoft Entra ID non hanno necessariamente un proprietario, l'opzione per selezionare il proprietario dell'applicazione come revisore non è possibile. Al contrario, quando si crea la revisione, è possibile specificare i nomi dei proprietari dell'applicazione come revisori.

È anche possibile scegliere, quando si crea una revisione di un gruppo o di un'applicazione, per avere una revisione a più fasi. Ad esempio, è possibile selezionare per fare in modo che il responsabile di ogni utente assegnato esegua la prima fase della revisione e il proprietario della risorsa la seconda fase. In questo modo il proprietario della risorsa può concentrarsi sugli utenti che sono già stati approvati dal manager.

Prima di creare le revisioni, verificare di disporre di postazioni sufficienti dello SKU di governance dell'ID Microsoft Entra P2 o Microsoft Entra ID Nel tenant. Verificare inoltre che tutti i revisori siano utenti attivi con indirizzi di posta elettronica. All'avvio delle verifiche di accesso, ogni utente esamina un messaggio di posta elettronica da Microsoft Entra ID. Se il revisore non dispone di una cassetta postale, non riceverà il messaggio di posta elettronica all'avvio della revisione o a un promemoria tramite posta elettronica. Inoltre, se non sono in grado di accedere a Microsoft Entra ID, non potranno eseguire la revisione.

Configurare le verifiche di accesso o la gestione entitlement

Dopo che gli utenti si trovano nei ruoli dell'applicazione e i revisori sono identificati, è possibile gestire gli utenti e gli altri utenti che avranno bisogno di accesso, usando verifiche di accesso o gestione entitlement.

Esaminare e rimuovere l'accesso esistente usando una verifica di accesso delle assegnazioni di ruolo dell'app

Se l'applicazione ha più ruoli applicazione, è rappresentata da più entità servizio oppure si vuole disporre di un processo per richiedere o assegnare l'accesso all'applicazione, continuare con la sezione seguente di questo articolo per gestire l'accesso tramite la gestione entitlement.

Ora che gli utenti esistenti hanno assegnazioni a un ruolo applicazione, è possibile configurare l'ID Di Microsoft Entra per avviare una revisione di tali assegnazioni.

  1. Per questo passaggio, è necessario essere nel ruolo Amministratore globale o Amministratore della governance delle identità.

  2. Seguire le istruzioni nella guida per la creazione di una verifica di accesso di gruppi o applicazioni per creare la revisione delle assegnazioni di ruolo dell'applicazione. Configurare la revisione per applicare i risultati al termine. È possibile creare la verifica di accesso in PowerShell con il New-MgIdentityGovernanceAccessReviewDefinition cmdlet dei cmdlet di PowerShell di Microsoft Graph per il modulo Identity Governance . Per ulteriori informazioni, vedere gli esempi.

    Nota

    Se si abilitano gli helper decisionali di revisione durante la creazione della verifica di accesso, le raccomandazioni dell'helper decisionale sono basate sul periodo di 30 giorni a seconda del momento in cui l'utente ha eseguito l'ultimo accesso all'applicazione usando Microsoft Entra ID.

  3. Quando la verifica di accesso viene avviata, chiedere ai revisori di esprimere il proprio giudizio. Per impostazione predefinita, ognuno riceve un messaggio di posta elettronica da Microsoft Entra ID con un collegamento al pannello di accesso, in cui esamina l'accesso all'applicazione.

  4. Dopo aver avviato le verifiche, è possibile monitorare lo stato di avanzamento e aggiornare i responsabili approvazione, se necessario, fino al completamento della verifica di accesso. È quindi possibile confermare che gli utenti, il cui accesso è stato negato dai revisori, hanno l'accesso rimosso dall'applicazione.

  5. Se l'applicazione automatica non è stata selezionata al momento della creazione della revisione, sarà necessario applicare i risultati della revisione al termine.

  6. Attendere che lo stato della revisione venga modificato in Risultato applicato. Si prevede di visualizzare gli utenti negati, se presenti, in cui le assegnazioni di ruolo dell'applicazione vengono rimosse in pochi minuti.

  7. Dopo aver applicato i risultati, l'ID Microsoft Entra inizierà il deprovisioning degli utenti negati dall'applicazione. In base alle indicazioni relative al tempo necessario per effettuare il provisioning degli utenti, attendere che il provisioning di Microsoft Entra avvii il deprovisioning degli utenti negati. Monitorare lo stato del provisioning tramite il portale o le API Graph per assicurarsi che tutti gli utenti rifiutati siano stati rimossi correttamente.

    Se gli utenti non vengono sottoposti a deprovisioning, vedere la guida alla risoluzione dei problemi per nessun utente di cui è stato effettuato il provisioning. Se viene visualizzato un errore nello stato di provisioning e si esegue il provisioning in un'applicazione locale, vedere la guida alla risoluzione dei problemi per il provisioning di applicazioni locali.

Ora che si dispone di una baseline che garantisce che l'accesso esistente sia stato esaminato, è possibile continuare nella sezione successiva per configurare la gestione entitlement per abilitare nuove richieste di accesso.

Gestire l'accesso tramite la gestione entitlement

In altre situazioni, ad esempio la necessità di disporre di revisori diversi per ogni ruolo applicazione, l'applicazione è rappresentata da più entità servizio oppure si vuole avere un processo per richiedere o assegnare l'accesso all'applicazione, quindi è possibile configurare l'ID Di Microsoft Entra con un pacchetto di accesso per ogni ruolo applicazione. Ogni pacchetto di accesso può avere un criterio per la revisione ricorrente delle assegnazioni effettuate a tale pacchetto di accesso. Dopo aver creato i pacchetti di accesso e i criteri, è possibile assegnare gli utenti con assegnazioni di ruolo applicazione esistenti ai pacchetti di accesso, in modo che le assegnazioni possano essere esaminate tramite il pacchetto di accesso.

In questa sezione si configurerà la gestione entitlement di Microsoft Entra per una verifica delle assegnazioni dei pacchetti di accesso che contengono le assegnazioni di ruolo dell'app e si configureranno anche criteri aggiuntivi in modo che gli utenti possano richiedere l'accesso ai ruoli dell'applicazione.

  1. Per questo passaggio, è necessario trovarsi nel ruolo Amministratore globale o Amministratore della governance delle identità oppure essere delegato come creatore del catalogo e proprietario dell'applicazione.
  2. Se non si ha già un catalogo per lo scenario di governance delle applicazioni, creare un catalogo nella gestione entitlement di Microsoft Entra. È possibile usare uno script di PowerShell per creare ogni catalogo.
  3. Popolare il catalogo con le risorse necessarie, aggiungendo l'applicazione e tutti i gruppi di Microsoft Entra su cui si basa l'applicazione, come risorse in tale catalogo. È possibile usare uno script di PowerShell per aggiungere ogni risorsa a un catalogo.
  4. Per ognuna delle applicazioni e per ogni ruolo o gruppo dell'applicazione, creare un pacchetto di accesso che includa tale ruolo o gruppo come risorsa. In questa fase di configurazione di questi pacchetti di accesso, configurare i primi criteri di assegnazione dei pacchetti di accesso in ogni pacchetto di accesso come criteri per l'assegnazione diretta, in modo che solo gli amministratori possano creare assegnazioni con tale criterio, impostare i requisiti di verifica di accesso per gli utenti esistenti, se presenti, in modo che non mantengano l'accesso illimitato. Se si dispone di molti pacchetti di accesso, è possibile usare uno script di PowerShell per creare ciascun pacchetto di accesso in un catalogo.
  5. Per ogni pacchetto di accesso assegnare gli utenti esistenti dell'applicazione nel ruolo corrispondente o i membri di tale gruppo al pacchetto di accesso e ai relativi criteri di assegnazione diretta. È possibile assegnare direttamente un utente a un pacchetto di accesso usando l'Interfaccia di amministrazione di Microsoft Entra o in blocco tramite Graph o PowerShell.
  6. Se sono state configurate le verifiche di accesso nei criteri di assegnazione dei pacchetti di accesso, quando viene avviata la verifica di accesso, chiedere ai revisori di fornire input. Per impostazione predefinita, ogni utente riceve un messaggio di posta elettronica da Microsoft Entra ID con un collegamento al pannello di accesso, in cui esamina le assegnazioni dei pacchetti di accesso. Al termine della verifica, è consigliabile visualizzare gli utenti negati, se presenti, dopo aver rimosso le assegnazioni di ruolo dell'applicazione in pochi minuti. Successivamente, Microsoft Entra ID avvierà il deprovisioning degli utenti negati dall'applicazione. In base alle indicazioni relative al tempo necessario per effettuare il provisioning degli utenti, attendere che il provisioning di Microsoft Entra avvii il deprovisioning degli utenti negati. Monitorare lo stato del provisioning tramite il portale o le API Graph per assicurarsi che tutti gli utenti rifiutati siano stati rimossi correttamente.
  7. Se si hanno dei requisiti di separazione dei compiti, configurare i pacchetti di accesso incompatibili o i gruppi esistenti per il pacchetto di accesso. Se lo scenario richiede la possibilità di eseguire l'override di una separazione dei compiti, è possibile anche configurare pacchetti di accesso aggiuntivi per questi scenari di override.
  8. Se si vuole consentire agli utenti che non hanno già accesso per richiedere l'accesso, in ogni pacchetto di accesso creare criteri di assegnazione dei pacchetti di accesso aggiuntivi per consentire agli utenti di richiedere l'accesso. Configurare i requisiti di approvazione e verifica dell'accesso ricorrente in tale criterio.

Passaggi successivi