Gestire mapping e utenti nelle applicazioni che non corrispondono agli utenti in Microsoft Entra ID
Quando si integra un'applicazione esistente con Microsoft Entra ID, per il provisioning o l'accesso Single Sign-On (SSO), è possibile determinare se ci sono utenti nell'archivio dati dell'applicazione che non corrispondono agli utenti in Microsoft Entra ID o che non corrispondono agli utenti di Microsoft Entra ID.
Il servizio di provisioning di Microsoft Entra si basa su regole di corrispondenza configurabili per determinare se un utente in Microsoft Entra ID corrisponde a un utente nell'applicazione, cercando nell'applicazione un utente con la proprietà di corrispondenza di un utente di Microsoft Entra ID. Si supponga, ad esempio, che la regola di corrispondenza sia confrontare l'attributo userPrincipalName
di un utente di Microsoft Entra ID con la proprietà userName
di un'applicazione. Quando a un utente in Microsoft Entra ID con valore userPrincipalName
di alice.smith@contoso.com
viene assegnato il ruolo di un'applicazione, il servizio di provisioning di Microsoft Entra esegue una ricerca dell'applicazione, con una query come userName eq "alice.smith@contoso.com"
. Se la ricerca dell'applicazione indica che non c'è alcun utente corrispondente, il servizio di provisioning di Microsoft Entra crea un nuovo utente nell'applicazione.
Se nell'applicazione non ci sono già utenti, questo processo popola l'archivio dati dell'applicazione con gli utenti man mano che vengono assegnati in Microsoft Entra ID. Tuttavia, se nell'applicazione ci sono già utenti, possono verificarsi due situazioni. Prima situazione: nell'applicazione potrebbero essere presenti persone con account utente tuttavia la corrispondenza non riesce a individuarli; l'utente potrebbe essere rappresentato nell'applicazione come asmith@contoso.com
anziché alice.smith@contoso.com
e quindi la ricerca eseguita dal servizio di provisioning di Microsoft Entra non lo trova. In tale situazione, la persona potrebbero esserci utenti duplicati nell'applicazione. Seconda situazione: nell'applicazione potrebbero essere presenti persone con account utente che non hanno un utente in Microsoft Entra ID. In questo caso, il servizio di provisioning di Microsoft Entra non interagisce con gli utenti nell'applicazione, tuttavia, se l'applicazione è configurata in modo da basarsi su Microsoft Entra ID come unico provider di identità, tali utenti non potranno più eseguire l'accesso: l'applicazione reindirizzerà la persona all'accesso con Microsoft Entra ID, ma tale persona non ha un utente in Microsoft Entra ID.
Queste incoerenze tra Microsoft Entra ID e l'archivio dati di un'applicazione esistente possono verificarsi per molti motivi, tra cui:
- l'amministratore dell'applicazione crea gli utenti nell'applicazione direttamente, ad esempio per fornitori o terzisti, che non sono rappresentati in un sistema di record con fonte Risorse umane, ma richiedono l'accesso all'applicazione,
- le modifiche all'identità e all'attributo, ad esempio una persona che cambia il nome, non sono state inviate a Microsoft Entra ID o all'applicazione e quindi le rappresentazioni non sono aggiornate nell'uno o nell'altro sistema, oppure
- l'organizzazione usava un prodotto di gestione delle identità che effettuava il provisioning indipendente di Windows Server AD e dell'applicazione con community diverse. Ad esempio, i dipendenti del negozio avevano bisogno dell'accesso all'applicazione ma non richiedevano cassette postali Exchange, quindi non erano rappresentati in Windows Server AD o Microsoft Entra ID.
Prima di abilitare il provisioning o l'accesso SSO a un'applicazione con utenti esistenti, è necessario verificare che gli utenti corrispondano e analizzare e risolvere i casi degli utenti dall'applicazione che non corrispondono. Questo articolo illustra le opzioni per risolvere le diverse situazioni diverse di mancata corrispondenza di un utente.
Determinare se nell'applicazione sono presenti utenti che non hanno una corrispondenza
Se è già stato determinato l'elenco di utenti nell'applicazione che non corrispondono agli utenti in Microsoft Entra ID, continuare con la sezione successiva.
La procedura per determinare gli utenti nell'applicazione che non corrispondono agli utenti in Microsoft Entra ID dipende dal modo in cui l'applicazione è o verrà integrata con Microsoft Entra ID.
Se si usa SAP Cloud Identity Services, seguire l'esercitazione sul provisioning di SAP Cloud Identity Services fino al passaggio per assicurarsi che gli utenti esistenti di SAP Cloud Identity Services abbiano gli attributi di corrispondenza necessari. In questa esercitazione si esporta un elenco di utenti da SAP Cloud Identity Services in un file CSV e successivamente si usa PowerShell per associare tali utenti agli utenti in Microsoft Entra ID.
Se l'applicazione usa una directory LDAP, seguire l'esercitazione sul provisioning della directory LDAP fino al passaggio per raccogliere gli utenti esistenti dalla directory LDAP. In questa esercitazione usare PowerShell per trovare le corrispondenze degli utenti con gli utenti in Microsoft Entra ID.
Per altre applicazioni, incluse quelle con un database SQL o che dispongono del supporto per il provisioning nella raccolta di applicazioni, seguire l'esercitazione per gestire gli utenti esistenti di un'applicazione fino al passaggio per verificare che in Microsoft Entra ID sono presenti utenti che corrispondono agli utenti dell'applicazione.
Per altre applicazioni che non dispongono di un'interfaccia di provisioning, seguire l'esercitazione per gestire gli utenti di un'applicazione che non supporta il provisioning fino al passaggio per verificare che in Microsoft Entra ID siano presenti utenti che corrispondono agli utenti dell'applicazione.
Al termine dello script di PowerShell fornito in queste esercitazioni, viene visualizzato un errore se i record dell'applicazione non vengono individuati in Microsoft Entra ID. Se i record per gli utenti dell'archivio dati dell'applicazione non sono stati individuati tutti come utenti in Microsoft Entra ID, è necessario analizzare quali record non corrispondono e perché e quindi risolvere il problema di corrispondenza usando una delle opzioni nella sezione successiva.
Opzioni per assicurarsi che ci sia corrispondenza tra gli utenti dell'applicazione e Microsoft Entra ID
Questa sezione offre diverse opzioni per gestire gli utenti che non hanno una corrispondenza nell'applicazione. In base agli obiettivi dell'organizzazione e ai problemi di dati tra Microsoft Entra ID e l'applicazione, selezionare l'opzione appropriata per ogni utente. Ci potrebbero essere diverse opzioni che riguardano tutti gli utenti in una determinata applicazione.
Eliminare gli utenti di test dall'applicazione
Nell'applicazione potrebbero essere rimasti utenti di test dalla distribuzione iniziale. Se sono presenti utenti che non sono più necessari, è possibile eliminarli dall'applicazione.
Eliminare gli utenti dalle applicazioni per le persone che non fanno più parte dell'organizzazione
L'utente potrebbe non essere più associato all'organizzazione e potrebbe non avere più bisogno di accedere all'applicazione, ma è ancora presente nell'origine dati dell'applicazione. Ciò può verificarsi se l'amministratore dell'applicazione no ha rimosso l'utente o non è stato informato che era necessaria una modifica. Se l'utente non è più necessario, può essere eliminato dall'applicazione.
Eliminare gli utenti dall'applicazione e crearli nuovamente da Microsoft Entra ID
Se l'applicazione attualmente non è molto usata o non mantiene uno stato per utente, un'altra opzione consiste nell'eliminare gli utenti dall'applicazione in modo che non ci siano altri utenti non corrispondenti. Quindi, quando gli utenti richiedono o vengono assegnati all'applicazione in Microsoft Entra ID, verrà effettuato per loro il provisioning dell'accesso.
Aggiornare la proprietà di corrispondenza degli utenti nell'applicazione
Un utente può esistere in un'applicazione e in Microsoft Entra ID, ma all'utente nell'applicazione potrebbe mancare una proprietà necessaria per la corrispondenza oppure la proprietà ha un valore errato.
Ad esempio, quando un amministratore SAP crea un utente in SAP Cloud Identity Services usando la console di amministrazione, l'utente potrebbe non avere la proprietà userName
. Tuttavia, tale proprietà potrebbe essere quella usata per la corrispondenza con gli utenti in Microsoft Entra ID. Se la proprietà userName
è quella necessaria alla corrispondenza, l'amministratore SAP deve aggiornare gli utenti esistenti di SAP Cloud Identity Services per avere un valore della proprietà userName
.
Per un altro esempio, l'amministratore dell'applicazione ha impostato l'indirizzo e-mail dell'utente come proprietà mail
dell'utente nell'applicazione, quando l'utente è stato aggiunto per la prima volta all'applicazione. Tuttavia, in seguito l'indirizzo e-mail della persona e userPrincipalName
è stato modificato in Microsoft Entra ID. Se l'applicazione non ha richiesto l'indirizzo e-mail o il provider di posta elettronica prevedeva un reindirizzamento che consentiva al vecchio indirizzo e-mail di continuare a inoltrare le e-mail, tuttavia, l'amministratore dell'applicazione potrebbe non aver notato che era necessario aggiornare la proprietà mail
nell'origine dati dell'applicazione. Questa incoerenza può essere risolta dall'amministratore dell'applicazione, modificando la proprietà mail
per gli utenti dell'applicazione in modo che abbia un valore aggiornato o modificando la regola di corrispondenza, come descritto nelle sezioni seguenti.
Aggiornare gli utenti nell'applicazione con una nuova proprietà
Il precedente sistema di gestione delle identità di un'organizzazione potrebbe aver creato utenti nell'applicazione come utenti locali. Se l'organizzazione non ha un solo provider di identità al momento, per tali utenti nell'applicazione non era necessaria la correlazione delle proprietà con altri sistemi. Ad esempio, un prodotto precedente di gestione delle identità ha creato utenti in un'applicazione in base a una fonte Risorse umane autorevole. Tale sistema di gestione delle identità ha mantenuto la correlazione tra gli utenti creati nell'applicazione con la fonte Risorse umane e non ha fornito alcun identificatore della fonte Risorse umane all'applicazione. Successivamente, quando si tenta di connettere l'applicazione a un tenant di Microsoft Entra ID popolato dalla stessa fonte Risorse umane, in Microsoft Entra ID potrebbero essere presenti utenti per le stesse persone dell'applicazione, ma la corrispondenza ha esito negativo per tutti gli utenti perché non c'è alcuna proprietà in comune.
Per risolvere questo problema di corrispondenza, eseguire questa procedura.
- Selezionare una proprietà inutilizzata esistente degli utenti nell'applicazione oppure aggiungere una nuova proprietà allo schema utenti nell'applicazione.
- Popolare tale proprietà in tutti gli utenti dell'applicazione con i dati di una fonte autorevole, ad esempio il numero ID o l'indirizzo e-mail di un dipendente, già presente negli utenti di Microsoft Entra ID.
- Aggiornare la configurazione di mapping degli attributi per il provisioning dell'applicazione Microsoft Entra per l'applicazione in modo che questa proprietà sia inclusa nella regola di corrispondenza.
Modificare le regole o le proprietà di corrispondenza quando l'indirizzo e-mail non corrisponde al nome dell'entità utente
Per impostazione predefinita, alcuni mapping del servizio di provisioning di Microsoft Entra per le applicazioni inviano l'attributo userPrincipalName
in modo che corrisponda a una proprietà dell'indirizzo e-mail dell'applicazione. Alcune organizzazioni hanno indirizzi e-mail primari per i propri utenti distinti dal nome dell'entità utente. Se l'applicazione archivia l'indirizzo e-mail come proprietà dell'utente e non userPrincipalName
, è necessario modificare gli utenti nell'applicazione o la regola di corrispondenza.
- Se si prevede di usare l'accesso Single Sign-On da Microsoft Entra ID all'applicazione, è possibile modificare l'applicazione per aggiungere una proprietà all'utente in modo che contenga il valore di userPrincipalName. Popolare quindi tale proprietà in ogni utente dell'applicazione con il valore di userPrincipalName dell'utente di Microsoft Entra ID e aggiornare la configurazione del provisioning dell'applicazione Microsoft Entra in modo che questa proprietà sia inclusa nella regola di corrispondenza.
- Se non si prevede di usare l'accesso Single Sign-On da Microsoft Entra ID, un'alternativa consiste nell'aggiornare la configurazione di mapping degli attributi di provisioning dell'applicazione Microsoft Entra, in modo che corrisponda a un attributo dell'indirizzo e-mail dell'utente di Microsoft Entra nella regola di corrispondenza.
Aggiornare l'attributo di corrispondenza degli utenti in Microsoft Entra ID
In alcune situazioni, l'attributo usato per la corrispondenza ha un valore non aggiornato nell'utente di Microsoft Entra ID. Ad esempio, una persona ha modificato il nome, ma la modifica del nome non è stata apportata nell'utente di Microsoft Entra ID.
Se l'utente è stato creato e gestito esclusivamente in Microsoft Entra ID, è necessario aggiornarlo in modo che disponga degli attributi corretti. Se l'attributo dell'utente ha origine in un sistema upstream, ad esempio Windows Server AD o una fonte Risorse umane, è necessario modificare il valore nell'origine upstream e attendere che la modifica diventi visibile in Microsoft Entra ID.
Aggiornare le regole di provisioning di Microsoft Entra Connect Sync o Cloud Sync per sincronizzare gli utenti e gli attributi necessari
In alcune situazioni, un precedente sistema di gestione delle identità ha popolato gli utenti di Windows Server AD con un attributo appropriato che può funzionare come attributo di corrispondenza con un'altra applicazione. Ad esempio, se il sistema precedente di gestione delle identità è stato collegato a una fonte Risorse umane, nell'utente di AD l'attributo employeeId
è popolato da tale sistema precedente di gestione delle identità con l'ID dipendente dell'utente. Per un altro esempio, il sistema precedente di gestione delle identità ha scritto l'ID utente univoco dell'applicazione come attributo di estensione nello schema di Windows Server AD. Tuttavia, se nessuno di questi attributi è stato selezionato per la sincronizzazione in Microsoft Entra ID o gli utenti non rientrano nell'ambito della sincronizzazione in Microsoft Entra ID, la rappresentazione di Microsoft Entra ID della community di utenti potrebbe essere incompleta.
Per risolvere questo problema, è necessario modificare la configurazione di Microsoft Entra Connect Sync o Microsoft Entra Cloud Sync per garantire che tutti gli utenti appropriati in Windows Server AD che si trovano anche nell'applicazione siano inclusi nell'ambito del provisioning in Microsoft Entra ID e che gli attributi sincronizzati di tali utenti includono gli attributi che verranno usati a scopo di corrispondenza. Se si usa Microsoft Entra Connect Sync, vedere Microsoft Entra Connect Sync: configurare i filtri and Microsoft Entra Connect Sync: estensioni della directory. Se si usa Microsoft Entra Cloud Sync, vedere Mapping degli attributi in Microsoft Entra Cloud Sync e Estensioni della directory di Cloud Sync e mapping degli attributi personalizzati.
Aggiornare gli utenti in Microsoft Entra ID con un nuovo attributo
In alcune situazioni, l'applicazione può contenere un identificatore univoco per l'utente che non è attualmente archiviato nello schema di Microsoft Entra ID per l'utente. Ad esempio, se si usa SAP Cloud Identity Services, potrebbe essere necessario che l'ID utente SAP sia l'attributo di corrispondenza o se si usa un sistema Linux, è possibile che l'ID utente Linux sia l'attributo di corrispondenza. Tuttavia, tali proprietà non fanno parte dello schema utenti di Microsoft Entra ID e quindi probabilmente non sono presenti in nessuno degli utenti in Microsoft Entra ID.
Per usare un nuovo attributo per la corrispondenza, seguire questa procedura.
- Selezionare un attributo di estensione inutilizzato esistente in Microsoft Entra ID oppure estendere lo schema utenti di Microsoft Entra con un nuovo attributo.
- Popolare tale attributo su tutti gli utenti in Microsoft Entra ID con i dati di una fonte autorevole, ad esempio l'applicazione o un sistema Risorse umane. Se gli utenti vengono sincronizzati da Windows Server AD o ne viene effettuato il provisioning da un sistema Risorse umane, potrebbe essere necessario apportare tale modifica nell'origine upstream.
- Aggiornare la configurazione di mapping degli attributi per il provisioning dell'applicazione Microsoft Entra e includere questo attributo nella regola di corrispondenza.
Modificare le regole di corrispondenza impostando un attributo diverso già popolato in Microsoft Entra ID
Le regole di corrispondenza predefinite per le applicazioni nella raccolta di applicazioni si basano su attributi comunemente presenti in tutti gli utenti di Microsoft Entra ID per tutti i clienti Microsoft, ad esempio userPrincipalName
. Queste regole sono adatte ai test per utilizzo generico o al provisioning in una nuova applicazione che attualmente non ha utenti. Tuttavia, molte organizzazioni potrebbero avere già popolato gli utenti di Microsoft Entra ID con altri attributi rilevanti per la propria organizzazione, ad esempio un ID dipendente. Se è presente un altro attributo adatto per la corrispondenza, aggiornare la configurazione di mapping degli attributi per il provisioning dell'applicazione Microsoft Entra e includere questo attributo nella regola di corrispondenza.
Configurare il provisioning in ingresso da una fonte Risorse umane a Microsoft Entra ID
Idealmente, le organizzazioni che hanno effettuato il provisioning degli utenti in più applicazioni in modo indipendente, devono basarsi su identificatori comuni per gli utenti derivati da una fonte autorevole, ad esempio un sistema Risorse umane. Molti sistemi Risorse umane hanno proprietà che funzionano bene come identificatori, ad esempio employeeId
che può essere considerato univoco così che due persone non abbiano lo stesso ID dipendente. Se si dispone di una fonte Risorse umane, ad esempio Workday o SuccessFactors, l'uso di attributi come employeeId da tale origine può spesso creare una regola di corrispondenza appropriata.
Per usare un attributo con valori ottenuti da una fonte autorevole per la corrispondenza, eseguire questa procedura.
- Selezionare un attributo appropriato dello schema utente di Microsoft Entra ID oppure estendere lo schema utenti di Microsoft Entra con un nuovo attributo, i cui valori corrispondono a una proprietà equivalente di un utente nell'applicazione.
- Assicurarsi che la proprietà sia presente anche in una fonte Risorse umane per tutte le persone che hanno utenti in Microsoft Entra ID e nell'applicazione.
- Configurare il provisioning in ingresso da tale fonte Risorse umane a Microsoft Entra ID.
- Attendere che gli utenti in Microsoft Entra ID vengano aggiornati con nuovi attributi.
- Aggiornare la configurazione di mapping degli attributi per il provisioning dell'applicazione Microsoft Entra e includere questo attributo nella regola di corrispondenza.
Creare utenti in Windows Server AD per gli utenti dell'applicazione che necessitano di accesso continuo all'applicazione
Se ci sono utenti dell'applicazione che non corrispondono a una persona in una fonte Risorse umane autorevole, ma che richiederanno l'accesso alle applicazioni basate su Windows Server AD e alle applicazioni integrate con Microsoft Entra ID in futuro e l'organizzazione usa Microsoft Entra Connect Sync o Microsoft Entra Cloud Sync per effettuare il provisioning degli utenti da Windows Server AD a Microsoft Entra ID, allora è possibile creare un utente in Windows Server AD per ognuno di questi utenti che non erano già presenti.
Se gli utenti non richiedono l'accesso alle applicazioni basate su Windows Server AD, creare gli utenti in Microsoft Entra ID, come descritto nella sezione successiva.
Creare utenti in Microsoft Entra ID per gli utenti dell'applicazione che necessitano di accesso continuo all'applicazione
Se ci sono utenti dell'applicazione che non corrispondono a una persona in una fonte Risorse umane autorevole, ma che avranno bisogno di accesso continuo e saranno regolati da Microsoft Entra, è possibile creare utenti di Microsoft Entra per loro. È possibile creare utenti in blocco usando:
- Un file CSV, come descritto in Creare utenti in blocco nell'Interfaccia di amministrazione di Microsoft Entra
- Il cmdlet New-MgUser
Assicurarsi che questi nuovi utenti vengano popolati con gli attributi necessari per Microsoft Entra ID per associarli in un secondo momento agli utenti esistenti nell'applicazione e con gli attributi richiesti da Microsoft Entra ID, inclusi userPrincipalName
, mailNickname
e displayName
. Il valore di userPrincipalName
deve essere univoco tra tutti gli utenti nella directory.
Creazione di utenti in blocco con PowerShell
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 ha già una sessione di PowerShell in cui sono stati identificati gli utenti nell'applicazione che non erano presenti in Microsoft Entra ID, continuare con il passaggio 6 seguente. In caso contrario, aprire PowerShell.
Se i moduli di Microsoft Graph PowerShell non sono già installati, installare il modulo
Microsoft.Graph.Users
e altri moduli 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
Connettersi a Microsoft Entra ID:
$msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All"
Se si usa questo comando per la prima volta, sarà necessario fornire il consenso per consentire agli strumenti della riga di comando di Microsoft Graph di avere queste autorizzazioni.
Nell'ambiente PowerShell inserire una matrice di utenti dell'applicazione, che include anche i campi che sono gli attributi obbligatori di Microsoft Entra ID, ovvero il nome dell'entità utente, il nome alternativo di posta elettronica e il nome completo dell'utente. Questo script presuppone che la matrice
$dbu_not_matched_list
contenga gli utenti dell'applicazione che non hanno una corrispondenza.$filename = ".\Users-to-create.csv" $bu_not_matched_list = Import-Csv -Path $filename -Encoding UTF8
Nella sessione di PowerShell specificare le colonne nella matrice di utenti da creare che corrispondono alle proprietà obbligatorie di Microsoft Entra ID. 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 colonnaAlias
contiene il nome alternativo di posta elettronica di Microsoft Entra ID e il valore nella colonnaFull 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"
Aprire lo script seguente in un editor di testo. Potrebbe essere necessario modificare questo script per aggiungere gli attributi di Microsoft Entra necessari per l'applicazione oppure se
$azuread_match_attr_name
nonmailNickname
è ouserPrincipalName
, al fine si specificare l'attributo di 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 } }
Incollare lo script risultante dall'editor di testo nella sessione di PowerShell. Se si verificano errori, è necessario correggerli prima di procedere.
Mantenere utenti separati e senza corrispondenza nell'applicazione e in Microsoft Entra ID
Nell'origine dati dell'applicazione potrebbe essere presente un utente con privilegi avanzati che non corrisponde a una persona specifica in Microsoft Entra ID. Se per tale utente non si creano utenti di Microsoft Entra, essi non potranno essere gestiti da Microsoft Entra ID o Microsoft Entra ID Governance. Poiché questi utenti non saranno in grado di accedere con Microsoft Entra ID, se si sta configurando l'applicazione per l'uso di Microsoft Entra ID come provider di identità, assicurarsi che tali utenti non siano inclusi nell'ambito di utilizzo di Microsoft Entra ID per l'autenticazione.
Nuova esportazione di utenti
Dopo aver eseguito gli aggiornamenti agli utenti di Microsoft Entra, agli utenti nell'applicazione o alle regole di corrispondenza dell'applicazione Microsoft Entra, è necessario esportare nuovamente ed eseguire di nuovo la procedura di corrispondenza per l'applicazione, per assicurarsi che tutti gli utenti siano correlati.
Se si usa SAP Cloud Identity Services, seguire l'esercitazione sul provisioning di SAP Cloud Identity Services a partire dal passaggio per assicurarsi che gli utenti esistenti di SAP Cloud Identity Services abbiano gli attributi di corrispondenza necessari. In questa esercitazione si esporta un elenco di utenti da SAP Cloud Identity Services in un file CSV e successivamente si usa PowerShell per associare tali utenti agli utenti in Microsoft Entra ID.
Se l'applicazione usa una directory LDAP, seguire l'esercitazione sul provisioning della directory LDAP a partire dal passaggio per raccogliere gli utenti esistenti dalla directory LDAP.
Per altre applicazioni, incluse quelle con un database SQL o che dispongono del supporto per il provisioning nella raccolta di applicazioni, seguire l'esercitazione per gestire gli utenti esistenti di un'applicazione a partire dal passaggio per verificare per raccogliere gli utenti esistenti dell'applicazione.
Assegnare utenti ai ruoli dell'applicazione e abilitare il provisioning
Dopo aver completato gli aggiornamenti necessari e aver verificato che tutti gli utenti dell'applicazione corrispondano agli utenti in Microsoft Entra ID, è necessario assegnare gli utenti in Microsoft Entra ID che devono accedere all'applicazione al ruolo app dell'applicazione Microsoft Entra e quindi abilitare il provisioning nell'applicazione.
- Se si usa SAP Cloud Identity Services, continuare a seguire l'esercitazione sul provisioning di SAP Cloud Identity Services a partire dal passaggio per assicurarsi che gli utenti esistenti di Microsoft Entra abbiano gli attributi necessari.