Migrazione degli utenti a Microsoft Entra External ID

In questa guida vengono illustrati i concetti fondamentali su come eseguire la migrazione di utenti e credenziali dal provider di identità corrente, incluso Azure AD B2C, all'ID esterno di Microsoft Entra. Questa guida illustra diverse soluzioni che è possibile usare a seconda della configurazione corrente. Con ognuno di questi approcci, è necessario scrivere un'applicazione o uno script che usa l'API Microsoft Graph per creare account utente in ID esterno.

Importante

A partire dal 1° maggio 2025, Azure AD B2C non sarà più disponibile per l'acquisto per i nuovi clienti. Per altre informazioni, vedere Azure AD B2C è ancora disponibile per l'acquisto? nelle domande frequenti.

Prerequisiti

Prima di iniziare la migrazione degli utenti all'ID esterno, è necessario:

• Un tenant esterno. Per crearne uno, scegliere tra i metodi seguenti:
  • Usare l'estensione MICROSOFT Entra External ID per configurare un tenant esterno direttamente in Visual Studio Code.
  • Creare un nuovo tenant esterno nel centro di amministrazione di Microsoft Entra.

Preparazione: pulizia della directory

Prima di avviare il processo di migrazione degli utenti, è necessario dedicare il tempo necessario per pulire i dati nella directory del provider di identità legacy. In questo modo è possibile assicurarsi di eseguire solo la migrazione dei dati necessari e rendere il processo di migrazione più semplice.

• Identificare il set di attributi utente da archiviare in ID esterno ed eseguire la migrazione solo degli elementi necessari. Se necessario, è possibile creare attributi personalizzati all'interno dell'ID esterno per archiviare altri dati su un utente.
• Se si esegue la migrazione da un ambiente con più origini di autenticazione (ad esempio, ogni applicazione ha la propria directory utente), eseguire la migrazione a un account unificato in ID esterno. Potrebbe essere necessario applicare la propria logica di business per unire e riconciliare gli account per lo stesso utente da origini diverse.
• I nomi utente devono essere univoci per ogni account su External. Se più applicazioni usano nomi utente diversi, è necessario applicare la propria logica di business per riconciliare e unire gli account. Per la password, consentire all'utente di sceglierne una e impostarla nella directory. Solo la password scelta deve essere archiviata nell'account ID esterno.
• Rimuovere gli account utente inutilizzati o non eseguire la migrazione di account non aggiornati.

Fase 1: Migrazione dei dati utente

Il primo passaggio del processo di migrazione consiste nel eseguire la migrazione dei dati utente dal provider di identità legacy all'ID esterno. Sono inclusi i nomi utente e qualsiasi altro attributo pertinente. A tale scopo, è necessario:

1. Leggi gli account utente dal tuo provider di identità legacy.
2. Creare gli account utente corrispondenti nella directory ID esterna. Per informazioni sulla creazione di account utente a livello di codice, vedere Gestire gli account utente consumer con Microsoft Graph.
3. Se si ha accesso alle password di testo non crittografato degli utenti, è possibile impostarle direttamente sui nuovi account durante la migrazione dei dati utente. Se non si ha accesso alle password in testo non crittografato, è necessario impostare una password casuale per il momento che verrà aggiornata in un secondo momento come parte del processo di migrazione delle password.

Non tutte le informazioni nel tuo fornitore di identità legacy devono essere migrate nella tua directory ID esterna. I consigli seguenti consentono di determinare il set appropriato di attributi utente da archiviare in ID esterno.

Conservare nell'ID esterno:

• Nome utente, password, indirizzi di posta elettronica, numeri di telefono, numeri di appartenenza/identificatori.
• Marcatori di consenso per l'informativa sulla privacy e i contratti di licenza dell'utente finale.

NON archiviare in identificativo esterno:

• Dati sensibili come numeri di carta di credito, numeri di previdenza sociale (SSN), cartelle cliniche o altri dati regolamentati da enti pubblici o di conformità del settore.
• Preferenze di marketing o di comunicazione, comportamenti degli utenti e informazioni dettagliate.

Fase 2: Migrazione delle password

Dopo aver eseguito la migrazione dei dati utente, è necessario eseguire la migrazione delle password utente dal provider di identità legacy all'ID esterno. Esistono due approcci consigliati per la migrazione delle password utente: reimpostazione della password self-service (SSPR) e migrazione senza problemi. Se le password utente in testo non crittografato non sono accessibili, è necessario usare uno di questi metodi. Ad esempio, se:

• La password viene archiviata in Azure AD B2C.
• La password viene archiviata in un formato crittografato unidirezionale, ad esempio con una funzione hash.
• La password viene archiviata dal provider di identità legacy in modo che non sia possibile accedere. Ad esempio, quando il provider di identità convalida le credenziali chiamando un servizio Web.

Reimpostazione automatica della password

Usando la funzionalità di reimpostazione della password self-service (SSPR) in External ID, i clienti possono impostare manualmente la password per la prima volta che accedono al nuovo sistema. Questo approccio è semplice da implementare e non richiede codice personalizzato. Tuttavia, richiede agli utenti di reimpostare manualmente le password, che potrebbero risultare scomode per alcuni utenti.

Per utilizzare questo approccio, è innanzitutto necessario configurare SSPR nel tenant di ID esterno e impostare i criteri di reimpostazione della password. È quindi necessario fornire agli utenti istruzioni su come reimpostare le password usando SSPR durante il loro primo accesso. Ad esempio, è possibile inviare un messaggio di posta elettronica agli utenti con istruzioni su come reimpostare le password o aggiungere istruzioni nell'app prima che l'utente passi al flusso di accesso.

Migrazione senza problemi

Se si ha un numero elevato di utenti o se si vuole offrire un'esperienza più semplice, è possibile usare l'approccio alla migrazione senza problemi. Questo processo consente agli utenti di continuare a usare le password esistenti durante la migrazione degli account all'ID esterno. A tale scopo, è necessario creare un'API REST personalizzata per convalidare le credenziali immesse dagli utenti rispetto al provider di identità legacy.

Il processo di migrazione facile è costituito dai passaggi seguenti:

1. Aggiungere un attributo di estensione agli account utente per contrassegnare lo stato della migrazione.
2. Quando un cliente accede, leggi l'account utente con ID esterno corrispondente all'indirizzo di posta elettronica immesso.
3. Se l'account di un cliente è già contrassegnato come migrato, continuare con il processo di accesso.
4. Se l'account dell'utente non è contrassegnato come già migrato, verificare la password immessa rispetto al provider di identità legacy.
   1. Se il provider di identità legacy determina che la password non è corretta, mostrare un errore amichevole all'utente.
   2. Se il provider di identità legacy determina che la password è corretta, utilizzare l'API REST per scrivere la password nell'account ID esterno e modificare l'attributo di estensione per contrassegnare l'account come migrato.

La migrazione facile avviene in due fasi. Prima di tutto, le credenziali legacy vengono raccolte e archiviate in ID esterno. Dopo aver aggiornato le credenziali per un numero sufficiente di utenti, è quindi possibile eseguire la migrazione delle applicazioni per l'autenticazione diretta con ID esterno. A questo punto gli utenti migrati possono continuare a usare le credenziali esistenti. Tutti gli utenti che non sono stati migrati dovranno reimpostare la password quando accedono per la prima volta.

La progettazione generale per il processo di migrazione facile è illustrata nel diagramma seguente:

Raccogli le credenziali dal fornitore di identità legacy e aggiorna gli account corrispondenti nel sistema ID esterno.

Interrompere la raccolta delle credenziali ed eseguire la migrazione delle applicazioni per l'autenticazione con ID esterno. Dismettere il provider di identità legacy.

Annotazioni

Se si usa questo approccio, è importante proteggere l'API REST da attacchi di forza bruta. Un utente malintenzionato può inviare diverse password nella speranza di indovinare le credenziali di un utente. Per risolvere tali attacchi, interrompere la gestione delle richieste all'API REST quando il numero di tentativi di accesso supera una determinata soglia.

Contenuti correlati

Se si esegue la migrazione da Azure AD B2C, il repository di esempio di migrazione utente facile in GitHub contiene un esempio di criteri personalizzati di migrazione semplice e un esempio di codice dell'API REST.