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 a Microsoft Entra ID dopo aver utilizzato 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 hanno il permesso di accedere a tale applicazione possono accedervi. 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 dell'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 utilizza 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 principale del servizio, se il Single Sign-On e il provisioning sono gestiti separatamente.

È possibile utilizzare anche i pacchetti di accesso di Microsoft Entra entitlement management per concedere agli utenti un accesso a tempo limitato all'applicazione. Nella gestione delle autorizzazioni, AccessPackage contiene uno o più ruoli delle risorse, potenzialmente da più principali di servizio. AccessPackage include anche assegnazioni (Assignment) per gli utenti al pacchetto di accesso.

Quando si crea un'assegnazione per un utente in un pacchetto di accesso, Microsoft Entra entitlement management crea automaticamente tutte le istanze necessarie AppRoleAssignment per l'utente al service principal di ogni applicazione nel pacchetto di accesso. Per ulteriori informazioni, consultare l'esercitazione Gestire l'accesso alle risorse nella gestione delle assegnazioni 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
  • Di 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. Esegui il comando che recupera il sottogruppo di utenti dalla tua 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 Conferma che l'ID Microsoft Entra abbia utenti che corrispondono agli utenti 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 pagina codice impostando 65001 (UTF-8).
  5. Completare la procedura guidata e selezionare l'opzione per l'avvio immediato.
  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 alla sezione Conferma che l'ID Microsoft Entra abbia utenti che corrispondono agli utenti 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 utilizza SQL Server, vedere l'elenco delle parole chiave e degli attributi delle stringhe di connessione e DSN.

    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 la stringa di connessione usando i seguenti comandi:

    $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 utilizzano i servizi SAP Cloud Identity come servizio di base per il provisioning degli utenti.

  1. Accedi alla console di amministrazione di SAP Cloud Identity Services, https://<tenantID>.accounts.ondemand.com/admino https://<tenantID>.trial-accounts.ondemand.com/admin se di prova.
  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 attributi SCIM ID, userName, emails e altri che puoi utilizzare 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 configurerai il provisioning di Microsoft Entra con mapping equivalenti. Questo passaggio consentirà al provisioning di Microsoft Entra di interrogare l'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 usano i servizi SAP Cloud Identity, il mapping predefinito è l'attributo userName SAP SCIM con l'attributo userPrincipalName Microsoft 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 in Microsoft Entra ID non si dispone di un attributo che ha un valore specifico e serve utilizzare un'espressione di filtro come contains o un'altra, sarà necessario personalizzare questo script e quello indicato nel passaggio 11 sottostante 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 qualcuno degli utenti presenti in SAP Cloud Identity Services, nel database o nella directory non può essere individuato in Microsoft Entra ID, a causa di errori o di mancate corrispondenze.

    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 essere individuati come utenti in Microsoft Entra ID, dovrai indagare quali record non hanno trovato corrispondenza e il motivo.

    Ad esempio, l'indirizzo di posta elettronica e l'userPrincipalName di un utente potrebbero essere stati modificati 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 super amministratore nella fonte 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 ulteriori attributi Microsoft Entra richiesti nella tua organizzazione, o se il $azuread_match_attr_name non è né mailNickname né userPrincipalName, al fine di fornire quell'attributo 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 nessun utente è assegnato ai ruoli dell'applicazione, il che indica che tutti gli utenti sono assegnati ai ruoli dell'applicazione, non sarà necessario apportare ulteriori 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. Usa questo comando per elencare i ruoli disponibili di un principale del 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à dell'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. Assicurati che Abbina oggetti utilizzando questo attributo sia impostato per l'attributo e la colonna Microsoft Entra usati nelle sezioni precedenti per l'abbinamento.

    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 una mappatura degli attributi per isSoftDeleted su un attributo dell'applicazione.

    Quando un utente viene disassegnato dall'applicazione, eliminato con la cancellazione temporanea in Microsoft Entra ID oppure bloccato dall'accesso, il processo di provisioning di Microsoft Entra aggiornerà l'attributo mappato a isSoftDeleted. Se non viene eseguito il mapping di alcun attributo, gli utenti che in seguito vengono rimossi dal ruolo dell'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 ruoli dell'applicazione 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 applicativo in Microsoft Entra ID per un utente in un'applicazione e l'applicazione supporta il provisioning, allora:

  • 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 prossima revisione delle assegnazioni di ruolo di quell'applicazione, l'utente verrà incluso nella revisione dell'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 alcuni utenti non sono assegnati ai ruoli dell'applicazione, controllare il log di controllo di Microsoft Entra per eventuali errori in un passaggio precedente.

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

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

  5. Monitorare lo stato di provisioning tramite il Portal o le API Graph per verificare che tutti gli utenti siano stati associati correttamente.

    Se non vedi utenti sottoposti a provisioning, consulta la guida alla risoluzione dei problemi per assenza di provisioning degli utenti. Se viene visualizzato un errore nello stato di provisioning e si esegue il provisioning per un'applicazione locale, controllare 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 un ErrorCode di DuplicateTargetEntries, ciò indica un'ambiguità nelle regole di corrispondenza del provisioning e sarà necessario aggiornare gli utenti di Microsoft Entra o le mappature utilizzate per l'abbinamento per garantire che ogni utente di Microsoft Entra corrisponda a un utente dell'applicazione. Filtrare quindi il log con l'azione Crea e lo 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 erano corrispondenti perché lo stato dell'account utente era Disabilitato.

Dopo che il servizio di provisioning di Microsoft Entra ha corrisposto gli utenti in base alle assegnazioni di ruolo dell'applicazione che hai creato, eventuali modifiche successive 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 un numero sufficiente di licenze Microsoft Entra ID P2 o Microsoft Entra ID Governance SKU 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 delle verifiche di accesso o la gestione dei diritti

Dopo che gli utenti si trovano nei ruoli dell'applicazione e i revisori sono stati identificati, puoi gestire quegli utenti e altri utenti aggiuntivi che necessiteranno di accesso, utilizzando le verifiche di accesso o la gestione delle autorizzazioni.

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

Se l'applicazione ha più ruoli applicativi, è rappresentata da più principali del servizio, o desideri avere un processo per consentire agli utenti di richiedere o ricevere l'accesso all'applicazione, continua con la sezione seguente di questo articolo per gestire l'accesso usando la gestione dei privilegi.

Ora che gli utenti esistenti hanno assegnazioni a un ruolo dell'applicazione, è possibile configurare Microsoft Entra ID 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 quando completa. È possibile creare la verifica di accesso in PowerShell utilizzando il cmdlet di New-MgIdentityGovernanceAccessReviewDefinition del modulo per il governo dell'identità di Microsoft Graph PowerShell. 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. Dovresti prevedere di vedere, se presenti, gli utenti a cui è stato negato l'accesso con l'eliminazione delle assegnazioni di ruolo dell'applicazione in pochi minuti.

  7. Dopo aver applicato i risultati, l'ID Microsoft Entra inizierà il deprovisioning degli utenti a cui è stato negato l'accesso dall'applicazione. In conformità con le indicazioni relative al tempo necessario per effettuare la provvisione degli utenti, aspettare che Microsoft Entra inizi a deprovvisionare gli utenti a cui è stato negato l'accesso. Monitorare lo stato del provisioning tramite il portale o le API di Graph per assicurarsi che tutti gli utenti negati siano stati rimossi correttamente.

    Se non vedi utenti sottoposti a deprovisioning, consulta la guida alla risoluzione dei problemi quando non vengono effettuati provisioning degli utenti. Se si verifica un errore nello stato di provisioning e si esegue il provisioning di un'applicazione locale, consultare 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.

Governare l'accesso tramite la gestione delle autorizzazioni

In altre situazioni, ad esempio la necessità di disporre di revisori diversi per ogni ruolo nell'applicazione, l'applicazione è rappresentata da più principali del servizio oppure si vuole avere un processo per richiedere o assegnare l'accesso all'applicazione, quindi è possibile configurare Microsoft Entra ID con un access package per ogni ruolo nell'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 dispone già di un catalogo per lo scenario di governance delle applicazioni, creare un catalogo nella gestione delle autorizzazioni di Microsoft Entra. È possibile usare uno script di PowerShell per creare ogni catalogo, come illustrato in creare un catalogo usando PowerShell.
  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, come illustrato in aggiungere l'applicazione come risorsa al 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 in modo che siano un criterio per l'assegnazione diretta, in modo che solo gli amministratori possano creare assegnazioni in 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 ogni pacchetto di accesso in un catalogo, come illustrato in creare un pacchetto di accesso per un'applicazione con un singolo ruolo.
  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 come illustrato in aggiungere assegnazioni di utenti esistenti.
  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 revisione, ci si deve aspettare che gli utenti a cui è stato negato, se presenti, vedano le loro assegnazioni di ruolo dell'applicazione rimosse entro 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 desidera consentire agli utenti che non hanno già accesso di richiedere l'accesso, in ogni pacchetto di accesso, creare criteri di assegnazione dei pacchetti di accesso supplementari affinché gli utenti possano fare richiesta di accesso. Configurare i requisiti di approvazione e revisione dell'accesso ricorrente in tale politica.

Passaggi successivi