• Cloud, Guide, Microsoft 365
• 5 Maggio 2026

Nel corso delle attività su ambienti Microsoft 365 vi sarà probabilmente capitato di incontrare tenant in cui gli utenti sono stati inizialmente creati direttamente nel cloud e solo in un secondo momento si è deciso di integrarli con l’infrastruttura locale tramite Microsoft Entra Connect Sync.

Quando avviate la sincronizzazione con Microsoft Entra ID, il motore tenta automaticamente di associare ogni oggetto on-premises a un oggetto già esistente nel tenant. Questo processo si basa su attributi chiave come userPrincipalName, proxyAddresses (in particolare l’indirizzo primario SMTP:) e sourceAnchor (immutableId). Se la corrispondenza avviene sugli attributi UPN o proxyAddresses si parla di Soft Match, mentre quando viene utilizzato l’immutableId si parla di Hard Match, che rappresenta il metodo più affidabile.

Se il matching va a buon fine, l’oggetto precedentemente gestito nel cloud viene convertito in oggetto sincronizzato e da quel momento la sorgente autorevole diventa Active Directory locale. Questo significa che gli attributi verranno sovrascritti dai valori on-premises e dovrete quindi assicurarvi che i dati locali siano corretti prima di procedere, perché ogni modifica dovrà essere gestita localmente e sincronizzata successivamente.

Nella pratica, però, capita spesso che queste attività non vengano gestite correttamente dai tecnici. In molti casi non viene configurato l’UPN Suffix corretto in Active Directory, lasciando domini interni non instradabili, e allo stesso tempo manca una corretta valorizzazione degli attributi proxyAddresses, soprattutto in scenari in cui in passato venivano utilizzate caselle di posta fornite da provider esterni e accessibili tramite POP3 o IMAP4.

Questo porta ad avere oggetti non allineati con il tenant di Microsoft Entra ID, aumentando la probabilità di errori durante la sincronizzazione. In questi casi entrano in gioco i meccanismi di protezione come la Duplicate Attribute Resiliency, che consente comunque al processo di proseguire anche in presenza di attributi duplicati o non univoci.

In presenza di conflitti su attributi univoci come UPN o proxyAddresses, il sistema non blocca la sincronizzazione dell’oggetto, ma isola l’attributo in conflitto. Ad esempio, se lo userPrincipalName è già in uso, viene assegnato temporaneamente un valore di tipo +[numeri]@tenant.onmicrosoft.com, permettendovi di completare la sincronizzazione e intervenire successivamente per correggere l’anomalia.

Utenti duplicati in Microsoft Entra ID dopo la sincronizzazione

Nella figura sotto viene mostrata la sezione Active users del portale Microsoft 365, dove sono presenti due oggetti con lo stesso display name ma con caratteristiche differenti.

L’elemento più importante da osservare è la colonna Sync status: l’icona con la nuvola identifica un utente cloud-only, mentre l’icona diversa indica un oggetto sincronizzato da Active Directory on-premises tramite Microsoft Entra Connect Sync.

In questo scenario avevate già un utente creato nel cloud con una determinata username. Durante la sincronizzazione, il sistema ha tentato di effettuare il matching con l’oggetto on-premises ma, non trovando una corrispondenza valida sugli attributi chiave, è entrata in gioco la funzionalità di Duplicate Attribute Resiliency di Microsoft Entra ID.

Il risultato è che non è stato fatto il match tra i due oggetti e quindi è stato creato un nuovo utente sincronizzato, assegnandogli automaticamente una username basata sul tenant di default (.onmicrosoft.com), evitando così il conflitto con l’utente già esistente.

Di fatto vi trovate con due identità distinte per lo stesso utente, una gestita nel cloud e una gestita on-premises, situazione che richiede un intervento manuale per essere corretta.

Figura 1: Esempio di duplicazione utenti in Entra ID a seguito di mancato matching e intervento della Duplicate Attribute Resiliency

Dopo aver consultato la documentazione ufficiale e aver corretto UPN e proxyAddresses, vi aspettereste che una nuova sincronizzazione risolva automaticamente il problema, ma in realtà la situazione non cambia.

Il punto è che, una volta che Microsoft Entra Connect Sync ha già creato un oggetto separato nel cloud senza effettuare il match, il processo di Soft Match non viene rieseguito nelle sincronizzazioni successive. Anche se ora gli attributi sono corretti, i due oggetti restano disaccoppiati.

Di conseguenza, vi trovate con un utente cloud e uno sincronizzato che rappresentano la stessa identità, ma che per Microsoft Entra ID sono entità completamente distinte. Per risolvere è necessario intervenire manualmente, perché la sola correzione degli attributi non è sufficiente.

Figura 2: Correzione dell’UPN in Active Directory

Figura 3: Correzione del proxy address in Active Directory

Risoluzione del problema con Hard Match e Microsoft Graph PowerShell

A questo punto dovete procedere con un Hard Match, cioè forzare l’associazione tra l’utente presente in Active Directory on-premises e l’oggetto già esistente in Microsoft Entra ID.

Per farlo è necessario lavorare con PowerShell e con il modulo Microsoft Graph PowerShell, recuperando il valore del sourceAnchor dell’utente locale e scrivendolo nell’attributo immutableId dell’utente cloud corretto.

In questo modo comunicate a Microsoft Entra ID che i due oggetti rappresentano la stessa identità e che, alla sincronizzazione successiva, devono essere collegati. Da quel momento l’utente cloud verrà convertito in oggetto sincronizzato da Active Directory on-premises.

Per installare il modulo PowerShell di Microsoft Graph potete seguire le indicazioni presenti alla pagina Connettersi a Microsoft 365 con Microsoft Graph PowerShell – Microsoft 365 Enterprise | Microsoft Learn

Dopo aver installato il modulo ed eseguito la connessione, stabilite una sessione autenticata verso Microsoft Entra ID con i permessi necessari per modificare gli utenti.

È fondamentale che la connessione venga effettuata con un account dotato di privilegi adeguati, perché dovrete intervenire su un attributo critico come immutableId, utilizzato per il Hard Match.

Figura 4: Installazione del modulo PowerShell di Microsoft Graph e autenticazione tramite account amministrativo

Durante la connessione Microsoft Entra ID richiede il consenso alle autorizzazioni necessarie per operare tramite Microsoft Graph PowerShell.

In questo passaggio dovete accettare i permessi richiesti dall’applicazione, in particolare quelli legati a lettura e scrittura dei profili utente, indispensabili per poter modificare l’attributo immutableId. Se operate come amministratori globali, potete anche concedere il consenso per tutta l’organizzazione, evitando richieste future.

Figura 5: Richiesta di consenso delle autorizzazioni per Microsoft Graph PowerShell

Subito dopo il consenso alle autorizzazioni, viene visualizzata la richiesta relativa al Single Sign-On sul dispositivo.

In questo caso dovete selezionare “No, solo questa app”, in modo da limitare l’accesso alla sola sessione di Microsoft Graph PowerShell senza registrare il dispositivo in Microsoft Entra ID.

Questa scelta è importante perché evita la registrazione non necessaria del server o della macchina amministrativa nel tenant, mantenendo l’operazione circoscritta all’attività che state svolgendo.

Figura 6: Scelta dell’opzione “No, solo questa app” per evitare la registrazione del dispositivo

Rimozione dell’utente cloud prima dell’Hard Match

Prima di procedere con l’Hard Match è necessario interrompere temporaneamente la sincronizzazione di Microsoft Entra Connect Sync, per evitare che l’oggetto venga ricreato automaticamente durante le operazioni. A questo punto dovete eliminare l’utente presente in Microsoft Entra ID utilizzando Microsoft Graph PowerShell.

Recuperate prima l’Id dell’utente, quindi procedete con la cancellazione. L’eliminazione avviene in due fasi: inizialmente l’utente viene spostato nei Deleted Users (soft delete) e successivamente potete eseguire la rimozione definitiva (hard delete).

È importante comprendere che con la prima operazione l’utente resta recuperabile per circa 30 giorni, mentre con la seconda viene eliminato definitivamente e non sarà più ripristinabile. Solo dopo questa pulizia potete procedere correttamente con il riallineamento degli oggetti e il successivo Hard Match.

Figura 7: Eliminazione completa dell’utente cloud tramite Microsoft Graph PowerShell (soft delete + hard delete)

Verifica della presenza del solo utente cloud originale dopo la rimozione del duplicato

A questo punto verificate che nel tenant di Microsoft Entra ID sia rimasto un solo utente, ovvero quello originario cloud-only e dotato di licenza.

Questo controllo è fondamentale perché vi assicura che l’oggetto duplicato, creato durante la sincronizzazione, sia stato completamente rimosso e che non esistano più conflitti. L’utente presente deve risultare con Sync status cloud (icona nuvola), confermando che non è attualmente collegato ad alcun oggetto on-premises.

Solo in questa condizione potete procedere in sicurezza con il riallineamento e il successivo Hard Match.

Figura 8: Verifica della presenza del solo utente cloud originale dopo la rimozione del duplicato

Cos’è l’ImmutableId e come viene generato durante la sincronizzazione

Per comprendere come funziona l’Hard Match è fondamentale chiarire il ruolo dell’immutableId in Microsoft Entra ID.

Durante la sincronizzazione con Microsoft Entra Connect Sync, ogni oggetto utente presente in Active Directory viene identificato in modo univoco tramite il valore sourceAnchor, che per impostazione predefinita corrisponde all’ObjectGUID dell’utente locale.

Questo valore viene convertito in formato Base64 e scritto in Microsoft Entra ID come immutableId. Si tratta di un identificatore univoco e persistente che consente al servizio di stabilire una relazione stabile tra oggetto on-premises e oggetto cloud.

È importante capire che l’immutableId non cambia nel tempo e viene utilizzato come riferimento principale per il matching deterministico (Hard Match). Quando impostate manualmente questo valore su un utente cloud, state dicendo esplicitamente al sistema quale oggetto locale deve essere associato.

Questo è il motivo per cui l’Hard Match è affidabile: a differenza del Soft Match, che si basa su attributi modificabili come UPN o email, l’immutableId rappresenta un legame univoco e non ambiguo tra le due identità.

Figura 9: Flusso di sincronizzazione delle identità: dall’ObjectGUID in Active Directory all’ImmutableId in Microsoft Entra ID tramite Entra Connect

Recupero dell’ImmutableId dall’Active Directory locale

Per ottenere il valore dell’immutableId dovete lavorare sull’Active Directory on-premises, perché è lì che risiede l’attributo ObjectGUID da cui deriva.

Potete eseguire questa operazione direttamente su un Domain Controller oppure installare il modulo Active Directory per PowerShell (RSAT) sulla macchina da cui state utilizzando Microsoft Graph PowerShell, così da avere tutto nello stesso ambiente operativo.

Prima recuperate l’ObjectGUID dell’utente e poi lo convertite in formato Base64, ottenendo il valore corretto da utilizzare come immutableId in Microsoft Entra ID.

Il valore restituito rappresenta l’identificatore univoco dell’utente on-premises ed è l’elemento chiave che utilizzerete per eseguire il Hard Match.

Figura 10: Recupero dell’ObjectGUID e conversione in immutableId da Active Directory

Impostazione dell’ImmutableId sull’utente cloud (Hard Match)

Una volta recuperato il valore dell’immutableId, dovete tornare sulla macchina dove avete configurato Microsoft Graph PowerShell e impostarlo sull’utente presente in Microsoft Entra ID.

In questo passaggio state eseguendo il vero Hard Match, perché associate manualmente l’oggetto cloud con quello on-premises tramite un identificatore univoco.

È fondamentale che il valore impostato sia corretto e corrispondente all’ObjectGUID dell’utente locale, perché da questo momento Microsoft Entra ID utilizzerà questo attributo per collegare definitivamente i due oggetti.

Figura 11: Impostazione manuale dell’immutableId tramite Microsoft Graph PowerShell per eseguire l’Hard Match

A questo punto potete riattivare la sincronizzazione di Microsoft Entra Connect Sync, che avevate precedentemente interrotto per eseguire le operazioni di pulizia e preparazione. Una volta ripristinato il ciclo di sync, il collegamento tramite immutableId verrà applicato e l’utente verrà correttamente gestito come oggetto sincronizzato.

Ora l’utente risulta con Sync status sincronizzato (icona diversa dalla nuvola), segno che l’oggetto cloud è stato correttamente collegato all’account on-premises. Questo conferma che l’Hard Match è avvenuto con successo e che esiste un unico oggetto gestito da Active Directory locale.

Da questo momento in poi dovrete gestire l’utente esclusivamente on-premises e ogni modifica verrà propagata in Microsoft Entra ID tramite la sincronizzazione.

Figura 12: Utente correttamente sincronizzato dopo Hard Match con immutableId

Conclusioni

Come avete visto, la gestione degli utenti duplicati in Microsoft Entra ID richiede attenzione soprattutto nelle fasi iniziali di sincronizzazione. Errori nella preparazione dell’Active Directory locale o un mancato matching possono portare facilmente alla creazione di oggetti duplicati.

La sola correzione di UPN e proxyAddresses non è sufficiente quando il matching è già fallito: in questi casi è necessario intervenire in modo esplicito tramite Hard Match, utilizzando l’attributo immutableId.

Seguendo la procedura corretta (rimozione dell’oggetto duplicato, recupero dell’ObjectGUID, conversione in Base64 e impostazione dell’immutableId) potete riallineare correttamente le identità ed evitare inconsistenze.

Il consiglio rimane sempre quello di preparare adeguatamente la directory on-premises prima della sincronizzazione, così da ridurre al minimo questo tipo di problematiche.