Funzionamento del provisioning delle applicazioni in Microsoft Entra ID

Articolo
10/24/2023

Il provisioning automatico si riferisce alla creazione di identità utente e ruoli nelle applicazioni cloud a cui gli utenti devono accedere. Oltre a creare le identità utente, il provisioning automatico include la manutenzione e la rimozione delle identità utente quando lo stato o i ruoli cambiano. Prima di iniziare una distribuzione, è possibile esaminare questo articolo per informazioni sul funzionamento del provisioning di Microsoft Entra e ottenere consigli sulla configurazione.

Il servizio di provisioning Di Microsoft Entra effettua il provisioning degli utenti alle app SaaS e ad altri sistemi connettendosi a un endpoint DELL'API di gestione utenti sciM (System for Cross-Domain Identity Management) 2.0 fornito dal fornitore dell'applicazione o da un agente di provisioning locale. Questo endpoint SCIM consente a Microsoft Entra ID di creare, aggiornare e rimuovere utenti a livello di codice. Per le applicazioni selezionate, il servizio di provisioning può anche creare, aggiornare e rimuovere oggetti aggiuntivi correlati all'identità, ad esempio i gruppi. Il canale usato per il provisioning tra Microsoft Entra ID e l'applicazione viene crittografato usando la crittografia HTTPS TLS 1.2.

Servizio di provisioning Microsoft Entra Figura 1: Servizio di provisioning di Microsoft Entra

Figura 2: Flusso di lavoro di provisioning utenti in uscita da Microsoft Entra ID a applicazioni SaaS comuni

Figura 3: Flusso di lavoro di provisioning utenti "Inbound" dalle applicazioni di Human Capital Management (HCM) più diffuse a Microsoft Entra ID e Windows Server Active Directory

Provisioning con SCIM 2.0

Il servizio di provisioning Microsoft Entra usa il protocollo SCIM 2.0 per il provisioning automatico. Il servizio si connette all'endpoint SCIM per l'applicazione e usa lo schema degli oggetti utente SCIM e le API REST per automatizzare il provisioning e il deprovisioning di utenti e gruppi. Per la maggior parte delle applicazioni della raccolta Microsoft Entra è disponibile un connettore di provisioning basato su SCIM. Gli sviluppatori usano l'API di gestione utenti SCIM 2.0 in Microsoft Entra ID per creare endpoint per le app che si integrano con il servizio di provisioning. Per informazioni dettagliate, vedere Creare un endpoint SCIM e configurare il provisioning utenti. L'agente di provisioning locale converte anche le operazioni SCIM di Microsoft Entra in LDAP, SQL, REST o SOAP, PowerShell, chiamate a un connettore ECMA personalizzato o connettori e gateway creati dai partner.

Per richiedere un connettore di provisioning Microsoft Entra automatico per un'app che non ne ha attualmente una, vedere Richiesta di applicazione Microsoft Entra.

Autorizzazione

Le credenziali sono necessarie per consentire a Microsoft Entra ID di connettersi all'API di gestione utenti dell'applicazione. Durante la configurazione del provisioning utenti automatico per un'applicazione, è necessario immettere credenziali valide. Per le applicazioni della raccolta, è possibile trovare i tipi di credenziali e i requisiti per l'applicazione facendo riferimento all'esercitazione sull'app. Per le applicazioni non della raccolta, è possibile fare riferimento alla documentazione SCIM per comprendere i tipi e i requisiti delle credenziali. Nell'interfaccia di amministrazione di Microsoft Entra è possibile testare le credenziali facendo in modo che Microsoft Entra ID tenti di connettersi all'app di provisioning dell'app usando le credenziali fornite.

Attributi di mapping

Quando si abilita il provisioning utenti per un'applicazione SaaS di terze parti, l'interfaccia di amministrazione di Microsoft Entra controlla i valori degli attributi tramite mapping degli attributi. I mapping determinano gli attributi utente che passano tra Microsoft Entra ID e l'applicazione di destinazione quando viene effettuato il provisioning o l'aggiornamento degli account utente.

È disponibile un set preconfigurato di attributi e mapping di attributi tra gli oggetti utente di Microsoft Entra e gli oggetti utente di ogni app SaaS. Alcune app gestiscono altri tipi di oggetti insieme a utenti e gruppi.

Quando si configura il provisioning, è importante esaminare e configurare i mapping degli attributi e i flussi di lavoro che definiscono quali proprietà utente (o gruppo) passano da Microsoft Entra ID all'applicazione. Rivedere e configurare la proprietà corrispondente (Abbina gli oggetti in base a questo attributo) che viene usata per identificare e abbinare in modo univoco utenti/gruppi tra i due sistemi.

È possibile personalizzare i mapping degli attributi predefiniti in base alle esigenze aziendali. Quindi è possibile modificare o eliminare i mapping degli attributi esistenti oppure crearne di nuovi. Per i dettagli, vedere Personalizzazione dei mapping degli attributi del provisioning utenti per le applicazioni SaaS.

Quando si configura il provisioning in un'applicazione SaaS, come mapping degli attributi è possibile specificare il mapping di espressioni. Per questo tipo di mapping è necessario scrivere un'espressione analoga a uno script, che permette di trasformare i dati utente in formati più idonei all'applicazione SaaS. Per i dettagli, vedere Scrittura di espressioni per i mapping degli attributi.

Scoping

Ambito basato sull'assegnazione

Per il provisioning in uscita da Microsoft Entra ID a un'applicazione SaaS, fare affidamento sulle assegnazioni di utenti o gruppi è il modo più comune per determinare quali utenti sono nell'ambito del provisioning. Poiché le assegnazioni utente vengono usate anche per l'abilitazione di Single Sign-On, è possibile usare lo stesso metodo per gestire l'accesso e il provisioning. L'ambito basato sull'assegnazione non si applica agli scenari di provisioning in ingresso, ad esempio giorni lavorativi e Successfactor.

Gruppi. Con un piano di licenza Microsoft Entra ID P1 o P2, è possibile usare i gruppi per assegnare l'accesso a un'applicazione SaaS. Quindi, quando l'ambito di provisioning è impostato su Sincronizza solo utenti e gruppi assegnati, il servizio di provisioning di Microsoft Entra effettua il provisioning o il deprovisioning degli utenti in base al fatto che siano membri di un gruppo assegnato all'applicazione. Non viene effettuato il provisioning dell'oggetto gruppo, a meno che l'applicazione non supporti gli oggetti gruppo. Assicurarsi che i gruppi assegnati all'applicazione dispongano della proprietà "SecurityEnabled" impostata su "True".
Gruppi dinamici. Il servizio di provisioning utenti Di Microsoft Entra può leggere ed effettuare il provisioning degli utenti in gruppi dinamici. Tenere presenti questi consigli e avvertenze:
- I gruppi dinamici possono influire sulle prestazioni del provisioning end-to-end da Microsoft Entra ID alle applicazioni SaaS.
- La velocità di provisioning o deprovisioning di un utente di un gruppo dinamico in un'applicazione SaaS dipende dalla velocità con cui il gruppo dinamico riesce a valutare le modifiche all'appartenenza. Per informazioni su come controllare lo stato di elaborazione di un gruppo dinamico, vedere Controllare lo stato di elaborazione per una regola di appartenenza.
- Quando un utente perde l'appartenenza al gruppo dinamico, viene considerato un evento di deprovisioning. Si consideri questo scenario quando si creano regole per i gruppi dinamici.
Gruppi annidati. Il servizio di provisioning utenti di Microsoft Entra non può leggere o effettuare il provisioning degli utenti in gruppi annidati. Può effettuare la lettura e il provisioning solo degli utenti che sono membri immediati del gruppo assegnato in modo esplicito. Si tratta di una limitazione delle "assegnazioni basate su gruppi alle applicazioni", che ha effetto anche su Single Sign-On e viene descritta in Uso di un gruppo per gestire l'accesso ad applicazioni SaaS. Come soluzione alternativa è consigliabile assegnare in modo esplicito o definire l'ambito nei gruppi contenenti gli utenti di cui è necessario effettuare il provisioning.

Ambito basato sugli attributi

È possibile usare i filtri di ambito per definire regole basate su attributi per determinare gli utenti per i quali viene eseguito il provisioning per un'applicazione. Questo metodo viene comunemente usato per il provisioning in ingresso da applicazioni HCM a Microsoft Entra ID e Active Directory. I filtri di ambito vengono configurati come parte dei mapping degli attributi per ogni connettore di provisioning utenti di Microsoft Entra. Per informazioni dettagliate sulla configurazione dei filtri di ambito basati su attributi, vedere Provisioning dell'applicazione basato su attributi con filtri per la definizione dell'ambito.

Utenti B2B (guest)

È possibile usare il servizio di provisioning utenti di Microsoft Entra per effettuare il provisioning degli utenti B2B (guest) nelle applicazioni SaaS in Microsoft Entra ID. Tuttavia, per consentire agli utenti B2B di accedere all'applicazione SaaS usando l'ID Microsoft Entra, è necessario configurare manualmente l'applicazione SaaS per usare Microsoft Entra ID come provider di identità SAML (Security Assertion Markup Language).

Seguire queste linee guida generali per la configurazione delle app SaaS per gli utenti B2B (guest):

Per la maggior parte delle app, la configurazione degli utenti deve essere eseguita manualmente. Gli utenti devono essere creati manualmente anche nell'app.
Per le app che supportano la configurazione automatica, come Dropbox, vengono creati inviti separati dalle app. Gli utenti devono assicurarsi di accettare ogni invito.
Negli attributi utente impostare sempre l'identificatore utente su user.mail su user.mail per attenuare eventuali problemi relativi al disco del profilo utente (UPD) degli utenti guest.

Nota

UserPrincipalName per un utente di Collaborazione B2B rappresenta l'indirizzo di posta elettronica dell'utente esterno alias@theirdomain come "alias_theirdomain#EXT#@yourdomain". Quando l'attributo userPrincipalName viene incluso nei mapping degli attributi come attributo di origine e viene eseguito il provisioning di un utente B2B, il #EXT# e il dominio viene rimosso dall'attributo userPrincipalName, quindi per la corrispondenza o il provisioning viene usato solo il relativo alias@theirdomain originale. Se è necessario che il nome dell'entità utente completo, incluso #EXT# e il dominio sia presente, sostituire userPrincipalName con originalUserPrincipalName come attributo di origine.
userPrincipalName = alias@theirdomain
originalUserPrincipalName = alias_theirdomain#EXT#@yourdomain

Cicli di provisioning: iniziali e incrementali

Quando Microsoft Entra ID è il sistema di origine, il servizio di provisioning usa la query delta per tenere traccia delle modifiche nei dati di Microsoft Graph per monitorare utenti e gruppi. Il servizio di provisioning esegue un ciclo iniziale rispetto al sistema di origine e a quello di destinazione, seguita da cicli incrementali periodici.

Ciclo iniziale

Quando viene avviato il servizio di provisioning, il primo ciclo consiste nelle operazioni seguenti:

Il servizio esegue una query su tutti gli utenti e i gruppi presenti nel sistema di origine e recupera tutti gli attributi definiti nei mapping degli attributi.
Il servizio filtra gli utenti e i gruppi restituiti, usando assegnazioni configurate o filtri di ambito basati su attributi.
Quando un utente viene assegnato o incluso nell'ambito per il provisioning, il servizio esegue una query sul sistema di destinazione per individuare un utente corrispondente usando gli attributi di corrispondenza specificati. Se ad esempio il nome userPrincipal nel sistema di origine è un attributo di corrispondenza ed è mappato a userName nel sistema di destinazione, il servizio di provisioning esegue una query sul sistema di destinazione per trovare i valori di userName che corrispondono ai valori del nome userPrincipal nel sistema di origine.
Se nel sistema di destinazione non viene trovato un utente corrispondente, questo viene creato usando gli attributi restituiti dal sistema di origine. Dopo aver creato l'account utente, il servizio di provisioning rileva e memorizza nella cache l'ID del sistema di destinazione per il nuovo utente. Questo ID viene usato per eseguire tutte le operazioni future su tale utente.
Se invece viene trovato un utente corrispondente, questo viene aggiornato usando gli attributi forniti dal sistema di origine. Dopo aver abbinato l'account utente, il servizio di provisioning rileva e memorizza nella cache l'ID del sistema di destinazione per il nuovo utente. Questo ID viene usato per eseguire tutte le operazioni future su tale utente.
Se i mapping degli attributi contengono attributi "reference", il servizio esegue altri aggiornamenti nel sistema di destinazione per creare e collegare gli oggetti a cui si fa riferimento. È ad esempio possibile che nel sistema di destinazione un utente abbia un attributo "Manager" collegato a un altro utente creato nel sistema di destinazione.
Al termine del ciclo iniziale, il servizio salva in modo permanente una filigrana che fornisce il punto di partenza per i successivi cicli incrementali.

Alcune applicazioni come ServiceNow, G Suite e Box supportano non solo il provisioning degli utenti ma anche quello dei gruppi e dei relativi membri. In questi casi, se nei mapping è abilitato il provisioning di gruppi, il servizio di provisioning sincronizza sia gli utenti che i gruppi e successivamente anche le appartenenze ai gruppi.

Cicli incrementali

Dopo il ciclo iniziale, tutti gli altri cicli consisteranno in quanto segue:

Il servizio esegue una query sul sistema di origine per trovare gli utenti e i gruppi che sono stati aggiornati dopo il salvataggio dell'ultima filigrana.
Il servizio filtra gli utenti e i gruppi restituiti, usando assegnazioni configurate o filtri di ambito basati su attributi.
Quando un utente viene assegnato o incluso nell'ambito per il provisioning, il servizio esegue una query sul sistema di destinazione per individuare un utente corrispondente usando gli attributi di corrispondenza specificati.
Se nel sistema di destinazione non viene trovato un utente corrispondente, questo viene creato usando gli attributi restituiti dal sistema di origine. Dopo aver creato l'account utente, il servizio di provisioning rileva e memorizza nella cache l'ID del sistema di destinazione per il nuovo utente. Questo ID viene usato per eseguire tutte le operazioni future su tale utente.
Se invece viene trovato un utente corrispondente, questo viene aggiornato usando gli attributi forniti dal sistema di origine. Se si tratta di un account appena assegnato e abbinato, il servizio di provisioning rileva e memorizza nella cache l'ID del sistema di destinazione per il nuovo utente. Questo ID viene usato per eseguire tutte le operazioni future su tale utente.
Se i mapping degli attributi contengono attributi "reference", il servizio esegue altri aggiornamenti nel sistema di destinazione per creare e collegare gli oggetti a cui si fa riferimento. È ad esempio possibile che nel sistema di destinazione un utente abbia un attributo "Manager" collegato a un altro utente creato nel sistema di destinazione.
Se un utente precedentemente incluso nell'ambito per il provisioning viene rimosso dall'ambito e la relativa assegnazione viene annullata, il servizio disabilita l'utente nel sistema di destinazione eseguendo un aggiornamento.
Se un utente precedentemente incluso nell'ambito per il provisioning viene disabilitato o eliminato temporaneamente nel sistema di origine, il servizio disabilita l'utente nel sistema di destinazione eseguendo un aggiornamento.
Se un utente precedentemente incluso nell'ambito per il provisioning viene eliminato definitivamente nel sistema di origine, il servizio elimina l'utente nel sistema di destinazione. In Microsoft Entra ID gli utenti vengono eliminati definitivamente 30 giorni dopo l'eliminazione temporanea.
Al termine del ciclo incrementale, il servizio salva in modo permanente una nuova filigrana che fornisce il punto di partenza per i successivi cicli incrementali.

Nota

È possibile disabilitare le operazioni di creazione, aggiornamento o eliminazione usando le caselle di controllo Azioni oggetto di destinazione nella sezione Mapping. La logica per disabilitare un utente durante un aggiornamento viene controllata anche tramite un mapping di attributi da un campo, ad esempio accountEnabled.

Il servizio di provisioning continuerà a eseguire cicli incrementali back-to-back all'infinito, in base agli intervalli definiti nell'esercitazione specifica di ogni applicazione. I cicli incrementali continuano fino a quando non si verifica uno degli eventi:

Il servizio viene arrestato manualmente tramite l'interfaccia di amministrazione di Microsoft Entra o usando il comando appropriato dell'API Microsoft Graph.
Viene attivato un nuovo ciclo iniziale usando l'opzione Riavvia provisioning nell'interfaccia di amministrazione di Microsoft Entra o usando il comando appropriato dell'API Microsoft Graph. L'azione cancella qualsiasi limite archiviato e fa in modo che tutti gli oggetti di origine vengano valutati nuovamente. Inoltre, l'azione non interrompe i collegamenti tra gli oggetti di origine e di destinazione. Per interrompere i collegamenti, usare Restart synchronizationJob con la richiesta:

POST https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/restart
Authorization: Bearer <token>
Content-type: application/json
{
   "criteria": {
       "resetScope": "Full"
   }
}

Viene attivato un nuovo ciclo iniziale a causa di una modifica nel mapping degli attributi o nei filtri di ambito. Per effetto di questa operazione, anche le eventuali filigrane salvate vengono cancellate e tutti gli oggetti di origine vengono nuovamente valutati.
Il processo di provisioning entra in quarantena (vedere l'esempio) a causa di un tasso di errore elevato e rimane in quarantena per più di quattro settimane. In questo caso, il servizio viene disabilitato automaticamente.

Errori e ripetizione di tentativi

Se non è possibile aggiungere, aggiornare o eliminare un singolo utente nel sistema di destinazione a causa di un errore in tale sistema, il tentativo di eseguire questa operazione viene ripetuto nel ciclo di sincronizzazione successivo. Gli errori vengono continuamente ritentati, ridimensionando gradualmente la frequenza dei tentativi. Per risolvere l'errore, gli amministratori devono verificare i log di provisioning per determinare la causa radice del problema e intraprendere l'azione appropriata. Tra gli errori comuni possono essere inclusi i seguenti:

Per gli utenti nel sistema di origine non è definito un valore di attributo che è necessario nel sistema di destinazione.
Per gli utenti nel sistema di origine è definito un valore di attributo per cui è impostato un vincolo univoco nel sistema di destinazione e lo stesso valore è presente in un altro record utente

Questi errori possono essere risolti modificando i valori di attributo per l'utente interessato nel sistema di origine o modificando i mapping degli attributi in modo da non causare conflitti.

Quarantena

Se la maggior parte o tutte le chiamate al sistema di destinazione non riuscono a causa di un errore (ad esempio nel caso di credenziali di amministratore non valide), il processo di provisioning passa allo stato di "quarantena". Questo stato è indicato nel report di riepilogo del provisioning e tramite posta elettronica se le notifiche di posta elettronica sono state configurate nell'interfaccia di amministrazione di Microsoft Entra.

In stato di quarantena, la frequenza dei cicli incrementali viene gradualmente ridotta fino a diventare giornaliera.

Dopo che tutti gli errori sono stati risolti, il processo di provisioning esce dalla quarantena e viene avviato il ciclo di sincronizzazione successivo. Se lo stato di quarantena dura per più di quattro settimane, il processo di provisioning viene disabilitato. Per altre informazioni sugli stati di quarantena, vedere qui.

Tempo richiesto per il provisioning

Le prestazioni variano a seconda che il processo di provisioning esegua un ciclo di provisioning iniziale o incrementale. Per informazioni dettagliate sul tempo necessario per il provisioning e su come monitorare lo stato del servizio di provisioning, vedere Controllare lo stato del provisioning dell'utente.

Come stabilire se il provisioning utenti viene eseguito correttamente

Tutte le operazioni eseguite dal servizio di provisioning utenti vengono registrate nei log di provisioning di Microsoft Entra (anteprima). Nei log sono incluse tutte le operazioni di lettura e scrittura eseguite nei sistemi di origine e di destinazione, oltre ai dati degli utenti che sono stati letti o scritti durante ogni operazione. Per informazioni su come leggere i log di provisioning nell'interfaccia di amministrazione di Microsoft Entra, vedere la guida alla creazione di report sul provisioning.

Deprovisioning

Il servizio di provisioning Di Microsoft Entra mantiene sincronizzati i sistemi di origine e di destinazione eseguendo il deprovisioning degli account quando l'accesso utente viene rimosso.

Il servizio di provisioning supporta sia l'eliminazione che la disabilitazione (talvolta definita eliminazione temporanea) degli utenti. La definizione esatta di disabilitazione ed eliminazione varia in base all'implementazione dell'app di destinazione, ma in genere una disabilitazione indica che l'utente non può accedere. Un'eliminazione indica che l'utente è stato rimosso completamente dall'applicazione. Per le applicazioni SCIM, una disabilitazione è una richiesta per impostare la proprietà attiva su false per un utente.

Configurare l'applicazione per disabilitare un utente

Verificare che la casella di controllo per gli aggiornamenti sia selezionata.

Confermare il mapping per l'applicazione attiva . Se si usa un'applicazione dalla raccolta di app, il mapping potrebbe essere leggermente diverso. In questo caso, usare il mapping predefinito per le applicazioni della raccolta.

Configurare l'applicazione per eliminare un utente

Lo scenario attiva una disabilitazione o un'eliminazione:

Un utente viene eliminato soft-delete in Microsoft Entra ID (inviato al Cestino/AccountEnabled proprietà impostato su false). Trenta giorni dopo l'eliminazione di un utente nell'ID Microsoft Entra, vengono eliminati definitivamente dal tenant. A questo punto, il servizio di provisioning invia una richiesta DELETE per eliminare definitivamente l'utente nell'applicazione. In qualsiasi momento durante la finestra di 30 giorni, è possibile eliminare manualmente un utente in modo permanente, operazione che invia una richiesta di eliminazione all'applicazione.
Un utente viene eliminato/rimosso definitivamente dal Cestino in Microsoft Entra ID.
Un utente non è assegnato da un'app.
Un utente passa dall'ambito all'esterno dell'ambito (non passa più un filtro di ambito).

Per impostazione predefinita, il servizio di provisioning di Microsoft Entra elimina o disabilita gli utenti che escono dall'ambito. Se si desidera eseguire l'override di questo comportamento predefinito, è possibile impostare un flag per ignorare le eliminazioni out-of-scope.

Quando si verifica uno dei quattro eventi e l'applicazione di destinazione non supporta le eliminazioni temporaneamente, il servizio di provisioning invia una richiesta DELETE per eliminare definitivamente l'utente dall'app.

Se vengono visualizzati IsSoftDeleted nei mapping degli attributi, viene usato per determinare lo stato dell'utente e se inviare una richiesta di aggiornamento con active = false per eliminare temporaneo l'utente.

Eventi di deprovisioning

La tabella descrive come configurare le azioni di deprovisioning con il servizio di provisioning Microsoft Entra. Queste regole vengono scritte con l'applicazione non raccolta/personalizzata, ma in genere si applicano alle applicazioni nella raccolta. Tuttavia, il comportamento per le applicazioni della raccolta può variare in quanto sono stati ottimizzati per soddisfare le esigenze dell'applicazione. Ad esempio, se l'applicazione di destinazione non supporta l'eliminazione temporanea, il servizio di provisioning di Microsoft Entra potrebbe inviare una richiesta di eliminazione temporanea per eliminare gli utenti anziché inviare un'eliminazione temporanea.

Scenario	Come configurare in Microsoft Entra ID
Un utente non è assegnato da un'app, eliminato soft-delete in Microsoft Entra ID o bloccato dall'accesso. Non vuoi fare niente.	Rimuovere `isSoftDeleted` dai mapping degli attributi e/o impostare la proprietà skip out of scope deletions su true.
Un utente non è assegnato da un'app, eliminato soft-delete in Microsoft Entra ID o bloccato dall'accesso. Si vuole impostare un attributo specifico su `true` o `false`.	Eseguire `isSoftDeleted` il mapping all'attributo che si desidera impostare su false.
Un utente è disabilitato in Microsoft Entra ID, non assegnato da un'app, eliminato soft-delete in Microsoft Entra ID o bloccato dall'accesso. Si vuole inviare una richiesta DELETE all'applicazione di destinazione.	Questa funzionalità è attualmente supportata per un set limitato di applicazioni della raccolta in cui è necessaria la funzionalità. Non è configurabile dai clienti.
Un utente viene eliminato in Microsoft Entra ID. Non si vuole eseguire alcuna operazione nell'applicazione di destinazione.	Assicurarsi che "Elimina" non sia selezionato come una delle azioni dell'oggetto di destinazione nell'esperienza di configurazione degli attributi.
Un utente viene eliminato in Microsoft Entra ID. Si vuole impostare il valore di un attributo nell'applicazione di destinazione.	Non supportato.
Un utente viene eliminato in Microsoft Entra ID. Si vuole eliminare l'utente nell'applicazione di destinazione	Assicurarsi che l'opzione Elimina sia selezionata come una delle azioni dell'oggetto di destinazione nell'esperienza di configurazione degli attributi.

Limitazioni note

Quando un utente o un gruppo non è assegnato da un'app e non è più gestito con il servizio di provisioning, viene inviata una richiesta di disabilitazione. A questo punto, il servizio non gestisce l'utente e una richiesta di eliminazione non viene inviata quando l'utente viene eliminato dalla directory.
Il provisioning di un utente disabilitato in Microsoft Entra ID non è supportato. Devono essere attivi in Microsoft Entra ID prima di eseguirne il provisioning.
Quando un utente passa da eliminazione temporanea ad attivo, il servizio di provisioning di Microsoft Entra attiva l'utente nell'app di destinazione, ma non ripristina automaticamente le appartenenze ai gruppi. L'applicazione di destinazione deve mantenere le appartenenze ai gruppi per lo stato inattivo dell'utente. Se l'applicazione di destinazione non supporta il mantenimento dello stato inattivo, è possibile riavviare il provisioning per aggiornare le appartenenze ai gruppi.

Consiglio

Quando si sviluppa un'applicazione, supporta sempre le eliminazioni temporanea e le eliminazioni predefinite. Consente ai clienti di eseguire il ripristino quando un utente è accidentalmente disabilitato.