Sincronizzare Active Directory con Azure AD (Microsoft Entra): guida completa senza duplicati e con UPN pubblico

Guida operativa, pratica e collaudata per portare ordine nella sincronizzazione tra Active Directory on‑premises e Azure AD (Microsoft Entra ID), eliminare i duplicati generati da tentativi precedenti e standardizzare gli UPN passando da .local a un suffisso pubblico routable, senza interrompere servizi come Power BI.

Indice

Scenario reale e problemi da risolvere

In molte organizzazioni gli utenti e i gruppi esistono sia on‑premises (Active Directory) sia in Azure AD, ma la sincronizzazione non avviene o è parziale. Le cause tipiche includono:

UPN on‑premises con suffisso non routable (mario@contoso.local), non accettato in Azure AD (Microsoft Entra ID).
Tentativi pregressi con Microsoft Entra Connect o Cloud Sync che hanno generato duplicati: un utente “cloud‑only” affiancato a un utente “synced”.
Mancato allineamento degli attributi critici (mail, proxyAddresses, sourceAnchor), che impedisce il soft‑match.

Obiettivi del progetto

Mantenere continuità operativa per Power BI e altri servizi Microsoft 365/Entra.
Eliminare ed evitare duplicati di identità.
Capire l’impatto del cambio UPN su applicazioni legacy e mitigarlo.
Disporre di una procedura passo‑passo, ripetibile e sicura.

Strategia in breve

Uniformare l’identità è la chiave. Azure AD accetta UPN con suffissi pubblici (routable). Quindi:

Verifica e aggiungi il dominio pubblico (es. contoso.com) nel tenant.
Configura il nuovo UPN suffix in Active Directory.
Aggiorna gli UPN on‑premises da .local a @contoso.com.
Allinea mail e proxyAddresses per abilitare il soft‑match.
Usa Microsoft Entra Connect Sync con Password Hash Sync e ms-DS-ConsistencyGuid come sourceAnchor (default).
Pulisci gli account cloud‑only in eccesso prima di rilanciare la sincronizzazione.
Verifica, pilota e poi apri a tutta l’organizzazione.

Soluzione consigliata (riassunto)

Passo	Azione	Dettagli / Motivo
Verificare un dominio pubblico	Aggiungi `contoso.com` in Azure AD → Custom domains e completa la verifica DNS.	Azure AD accetta solo suffissi routable.
Aggiungere l’UPN suffix in AD	In Active Directory Domains and Trusts → Alternate UPN suffixes → inserisci `contoso.com`.	Permette di assegnare il nuovo UPN agli utenti.
Aggiornare gli UPN on‑premises	Converti `utente@contoso.local` in `utente@contoso.com` (PowerShell o ADUC).	Rischi minimi: il logon Windows usa di norma `DOMINIO\samAccountName`; verifica app che salvano l’UPN.
Pre‑allineare gli attributi	Su ogni utente on‑prem imposta `mail`=UPN cloud e `proxyAddresses` con `SMTP:utente@contoso.com`.	Abilita il soft‑match (merge) con oggetti cloud esistenti.
Installare Microsoft Entra Connect Sync	Seleziona “Password Hash Sync” e lascia ms‑DS‑ConsistencyGuid come sourceAnchor.	Corrispondenza stabile e prevenzione duplicati.
Pulizia duplicati	Elimina o rinomina i cloud‑only non necessari prima della sync.	Evita conflitti al successivo ciclo di sincronizzazione.
Test & roll‑out	Esegui una prima sync, verifica in Azure AD → Users → Directory sync status.	Controlla che ogni utente risulti “Synced” e senza nuovi duplicati.

Prerequisiti e checklist

Accesso amministrativo a AD DS e al tenant Microsoft Entra.
Server dedicato (o VM) per Entra Connect Sync, con connettività verso DC e Internet.
Backup/export degli UPN correnti e dei proxyAddresses (CSV) per eventuale rollback.
Elenco delle applicazioni che potrebbero usare UPN come identificatore (es. SAML/SSO legacy, applicazioni on‑prem).
Definizione del dominio pubblico che diventerà UPN suffix primario (es. @contoso.com).

Procedura dettagliata passo‑passo

Verificare e aggiungere il dominio pubblico nel tenant

Apri il portale amministrativo e aggiungi Custom domain (es. contoso.com).
Completa la verifica DNS (record TXT/… secondo le istruzioni a schermo).
Imposta, se necessario, contoso.com come default domain per i nuovi oggetti.

Perché è cruciale: Azure AD non accetta UPN con .local o suffissi non pubblici.

Definire l’UPN suffix in Active Directory

Apri Active Directory Domains and Trusts.
Tasto destro su radice → Properties → scheda UPN Suffixes.
Aggiungi contoso.com e conferma.

Aggiornare gli UPN degli utenti on‑premises

Per sicurezza, inizia con un gruppo pilota (IT e power user). Poi estendi gradualmente.

Import-Module ActiveDirectory

ESEMPIO: cambio UPN in una OU specifica

$ou = "OU=Users,DC=contoso,DC=local"
Get-ADUser -Filter * -SearchBase $ou -Properties SamAccountName,UserPrincipalName |
ForEach-Object {
$newUpn = $*.SamAccountName + "@contoso.com"
if ($*.UserPrincipalName -ne $newUpn) {
Set-ADUser $_ -UserPrincipalName $newUpn
Write-Host "UPN aggiornato: $($_.UserPrincipalName) -> $newUpn"
}
}

EXPORT per rollback (prima di cambiare)

Get-ADUser -Filter * -SearchBase $ou -Properties UserPrincipalName |
Select-Object SamAccountName,UserPrincipalName |
Export-Csv .\Backup-UPN-before.csv -NoTypeInformation -Encoding UTF8

Impatto applicazioni: in genere il logon a Windows usa DOMINIO\samAccountName. Le app che si legano esplicitamente all’UPN (SSO SAML con NameID = UPN, sistemi HR/CRM più datati) richiedono test mirati. Gli SPN non sono toccati dal cambio UPN degli utenti standard; attenzione ai service account.

Pre‑allineare gli attributi per il soft‑match

Il soft‑match avviene quando l’oggetto on‑prem e quello cloud condividono lo stesso indirizzo SMTP primario in proxyAddresses (SMTP:utente@contoso.com). Imposta anche l’attributo mail coerente:

Import-Module ActiveDirectory

$ou = "OU=Users,DC=contoso,DC=local"
Get-ADUser -Filter * -SearchBase $ou -Properties mail,proxyAddresses,SamAccountName |
ForEach-Object {
$primary = $*.SamAccountName + "@contoso.com"
$proxies = @()
if ($*.proxyAddresses) { $proxies = @($_.proxyAddresses) }
```
# imposta SMTP primario se assente
if (-not ($proxies -match "^SMTP:$primary$")) {
  # rimuovi eventuali tag SMTP primari esistenti
  $proxies = $proxies | ForEach-Object { $_ -replace "^SMTP:", "smtp:" }
  $proxies += "SMTP:$primary"
  Set-ADUser $_ -Add @{proxyAddresses = $proxies } -Replace @{mail = $primary}
  Write-Host "proxyAddresses/mail aggiornati per $primary"
} else {
  if ($_.mail -ne $primary) {
    Set-ADUser $_ -Replace @{mail = $primary}
  }
}
```
}

Nota: nelle proxyAddresses il tag in maiuscolo SMTP: indica l’indirizzo primario; i secondari usano smtp: in minuscolo.

Installare e configurare Microsoft Entra Connect Sync

Prepara un server/VM dedicato (aggiornato, TLS 1.2, connettività verso DC e Internet).
Installa Entra Connect Sync con le opzioni consigliate:
- Metodo di autenticazione: Password Hash Sync (PHS). È semplice, resiliente e non richiede infrastruttura ADFS.
- SourceAnchor: lascia il default ms-DS-ConsistencyGuid; evita objectGUID per future migrazioni.
- Filtering: abilita OU filtering e inizia con la OU del pilota.
- Group writeback/Exchange hybrid: attiva solo se necessario.
Completata l’installazione, usa il Synchronization Service Manager (miisclient.exe) per monitorare gli stage.

Esegui cicli manuali quando serve:

# sul server Entra Connect
Start-ADSyncSyncCycle -PolicyType Initial    # prima esecuzione completa
in seguito:
Start-ADSyncSyncCycle -PolicyType Delta      # solo delta

Pulizia dei duplicati

Scenario A (consigliato): esistono utenti cloud‑only senza workload critici → elimina gli account cloud‑only corrispondenti prima di lanciare la sync (riduce il rischio di conflitti).

Scenario B (soft‑match): l’utente cloud‑only ha workload e dati (mailbox, Teams, OneDrive, Power BI) → non eliminare. Allinea proxyAddresses e mail on‑prem all’indirizzo primario usato in cloud, quindi avvia la sync: l’oggetto on‑prem verrà unito a quello cloud esistente senza perdita di dati. L’ObjectId cloud rimane il medesimo, preservando proprietà e autorizzazioni (inclusi workspace Power BI).

Test e roll‑out controllato

Lancia sync iniziale per il pilota e controlla in Azure AD lo stato “Directory sync: Enabled” e “On-premises sync enabled”.
Conferma che i profili risultino “Synced” e che non compaiano nuovi duplicati.
Estendi OU filtrate per on‑boarding progressivo (per reparto o sede).

# Verifica in Microsoft Graph PowerShell che gli utenti siano sincronizzati
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"
Get-MgUser -Filter "onPremisesSyncEnabled eq true" | Select-Object Id,DisplayName,UserPrincipalName

Se non puoi cambiare l’UPN on‑premises

Se il suffisso .local deve restare (vincoli applicativi), puoi abilitare l’Alternate sign‑in ID in Entra Connect (login con attributo mail invece del UPN). Considerazioni:

Maggiore complessità di gestione: gli utenti si autenticano con l’e‑mail, non con l’UPN AD.
Nel lungo periodo è preferibile migrare a un UPN pubblico per semplificare governance e troubleshooting.

Impatto del cambio UPN su sistemi esistenti

Componente	Impatto atteso	Note operative
Logon Windows	Basso	La maggior parte degli utenti usa `DOMINIO\samAccountName`; il cambio UPN non influisce.
Microsoft 365 (Exchange/Teams/SharePoint)	Basso	La sincronizzazione aggiorna l’identità; l’ObjectId cloud resta invariato in soft‑match.
Power BI	Basso	Con soft‑match, workspace e permessi restano ancorati allo stesso oggetto cloud.
SSO/Applicazioni SAML legacy	Medio	Se il NameID è l’UPN, aggiorna mapping/claim; valuta test pilota e finestra di change.
Service account / SPN	Variabile	Non cambiare UPN per account di servizio senza un’analisi dedicata.

FAQ rapide

Domanda	Risposta sintetica
Cambiare UPN rompe altri sistemi?	Di norma no. Windows usa `samAccountName`; i workload M365 si aggiornano. Testa solo app che usano l’UPN come chiave.
Procedura passo‑passo?	Verifica dominio → aggiungi suffix → cambia UPN → popola `mail`/`proxyAddresses` → installa Entra Connect → soft‑match → sync e verifica.

Gestione dei duplicati: strategie e casi

Come riconoscerli velocemente

In Azure AD, filtra utenti con Directory sync = Not synced e confrontali con gli on‑prem corrispondenti.
Verifica conflitti su proxyAddresses o userPrincipalName.

Soft‑match (consigliato)

Allinea l’indirizzo SMTP primario (SMTP:utente@contoso.com) nell’attributo proxyAddresses on‑prem al valore usato in cloud. Al ciclo successivo, Entra Connect unirà gli oggetti. Vantaggi: nessuna perdita di dati, ObjectId inalterato.

Hard‑match con ImmutableId (solo emergenza)

Se il soft‑match non è possibile (casi particolari), imposta l’ImmutableId del cloud‑only al valore base64 del msDS-ConsistencyGuid (o objectGUID se quello è il sourceAnchor). Questo approccio è avanzato e va eseguito in change window controllata.

# Ottenere l'ImmutableId corretto dall'on-prem
Import-Module ActiveDirectory
$user = Get-ADUser "mario.rossi" -Properties msDS-ConsistencyGuid,objectGUID
$anchor = if ($user.'msDS-ConsistencyGuid') { $user.'msDS-ConsistencyGuid' } else { $user.ObjectGUID }
$immutableId = [System.Convert]::ToBase64String($anchor.ToByteArray())

Impostare l'ImmutableId sul cloud user (modulo MSOnline storico)

Install-Module MSOnline -Scope CurrentUser
Connect-MsolService
Set-MsolUser -UserPrincipalName "[mario@contoso.com](mailto:mario@contoso.com)" -ImmutableId $immutableId

Attenzione: preferisci sempre il soft‑match. L’hard‑match richiede precisione e coordinamento, specie se sono assegnate licenze.

Cloud Sync vs Entra Connect Sync

Caratteristica	Entra Connect Sync	Entra Cloud Sync
Scenari	Standard, ambienti ibridi, Exchange hybrid, regole personalizzate.	Agente leggero, multi‑forest distribuiti, meno personalizzazioni.
SourceAnchor	`ms-DS-ConsistencyGuid` (consigliato)	Gestito dal servizio; meno controllo fine.
Regole avanzate/metaverse	Sì (Synchronization Rules Editor)	Limitato
Quando scegliere	La scelta predefinita per la maggior parte dei tenant con Exchange/Teams.	Quando serve agilità e non hai requisiti di ibrido Exchange complessi.

Filtraggio, scoping e staging

OU Filtering: sincronizza inizialmente solo la OU pilota; riduce l’impatto e accelera i test.
Attribute Filtering: usa con moderazione; mantieni gli attributi identitari standard.
Staging mode: configura un secondo server Entra Connect in staging come standby (non esporta). Utile per failover e per testare cambi.

Sincronizzazione dei gruppi

Allinea mail e proxyAddresses anche per i gruppi Mail‑enabled.
Evita nomi duplicati tra gruppi on‑prem e cloud‑only.
Per gruppi dinamici in cloud, la membership è calcolata in Azure AD e non viene “scritta” on‑prem.

Monitoraggio e verifica

# Stato scheduler su server Entra Connect
Get-ADSyncScheduler

Forza un delta sync

Start-ADSyncSyncCycle -PolicyType Delta

Elenco utenti sincronizzati (Graph)

Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"
Get-MgUser -Filter "onPremisesSyncEnabled eq true" |
Select-Object DisplayName,UserPrincipalName,OnPremisesImmutableId

Nel portale Entra verifica per campione che gli utenti mostrino Directory synced e che il campo Source of authority sia “Windows Server AD”.

Rollback e piano di contingenza

Backup CSV degli UPN/attributi prima del cambio.
Script di ripristino per riportare UPN a .local in caso di blocchi inattesi.
Staging mode per testare modifiche complesse senza esportare.

# Ripristino UPN da CSV di backup
Import-Module ActiveDirectory
$backup = Import-Csv .\Backup-UPN-before.csv
foreach ($row in $backup) {
  $user = Get-ADUser -Filter "SamAccountName -eq '$($row.SamAccountName)'" -Properties UserPrincipalName
  if ($user) { Set-ADUser $user -UserPrincipalName $row.UserPrincipalName }
}

Troubleshooting: errori frequenti e soluzioni

Errore/Evento	Causa probabile	Risoluzione
Duplicate attribute value su `proxyAddresses`	Stesso SMTP primario presente su più oggetti (utente/gruppo).	Rendi univoco l’indirizzo; rimuovi o correggi duplicati lato on‑prem.
User already exists in tenant	Oggetto cloud‑only con stessa identità previsto dalla sync.	Soft‑match (allinea SMTP primario) o rimuovi il cloud‑only prima di esportare.
InvalidSoftMatch	Match impossibile per conflitti su UPN/SMTP o attributi mancanti.	Verifica `proxyAddresses` primario e `mail` coerenti; ripeti sync.
UPN con suffisso non verificato	Dominio pubblico non verificato nel tenant.	Completa la verifica DNS del dominio.
Oggetto non esportato	OU non inclusa nel filtering.	Aggiungi l’OU al filtro, esegui delta sync.

Governance e sicurezza

Usa account di servizio per Entra Connect con privilegi minimi richiesti.
Abilita MFA sugli account amministrativi e registra contatti di emergenza del tenant.
Implementa Group‑based licensing in Azure AD per semplificare l’assegnazione licenze post‑sync.

Blueprint operativo completo

Preparazione: definisci dominio pubblico, mappa dipendenze UPN, esporta assetto attuale.
Abilitazione: verifica dominio in tenant, aggiungi UPN suffix in AD.
Allineamento identità: cambia UPN, imposta mail e proxyAddresses per soft‑match.
Installazione: configura Entra Connect Sync (PHS, ms‑DS‑ConsistencyGuid).
Pilotaggio: OU filtrata, sync iniziale, verifica “Synced”.
Pulizia: rimuovi cloud‑only indesiderati; conferma che non si creino nuovi duplicati.
Roll‑out: estendi a tutte le OU e pianifica eventuali finestre per app legacy.
Monitoraggio: schedulazione sync, audit log, report periodici.

Ricette PowerShell utili

Individuare potenziali duplicati (lato cloud)

Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"
$cloudOnly = Get-MgUser -All | Where-Object { -not $_.OnPremisesSyncEnabled }
$maybeDupes = $cloudOnly | Group-Object -Property UserPrincipalName,Mail | Where-Object { $_.Count -gt 1 }
$maybeDupes | ForEach-Object {
  $_.Group | Select-Object Id,DisplayName,UserPrincipalName,Mail
}

Verificare lo stato di sincronizzazione

Get-MgUser -Filter "onPremisesSyncEnabled eq true" |
  Select-Object DisplayName,UserPrincipalName,OnPremisesImmutableId |
  Format-Table -Auto

Allineare `proxyAddresses` in massa

Import-Module ActiveDirectory
$ou = "OU=Users,DC=contoso,DC=local"
Get-ADUser -Filter * -SearchBase $ou -Properties SamAccountName,proxyAddresses |
  ForEach-Object {
    $primary = $_.SamAccountName + "@contoso.com"
    $newList = @()
    if ($.proxyAddresses) { $newList = @($.proxyAddresses | ForEach-Object { $_ -replace "^SMTP:", "smtp:" }) }
    if (-not ($newList -match "^SMTP:$primary$")) { $newList += "SMTP:$primary" }
    Set-ADUser $_ -Replace @{ proxyAddresses = $newList }
  }

Checklist finale di esito

Ogni persona ha un unico oggetto utente (niente duplicati).
Stato utenti in Azure AD: Directory synced e On‑premises sync enabled.
Password sincronizzate (PHS) o, se scelto, Pass‑through Authentication.
Accesso uniforme ai servizi Microsoft 365/Entra (inclusi Power BI, Teams, Exchange).

Conclusioni

La chiave per una sincronizzazione affidabile è standardizzare l’identità su un UPN pubblico, allineare mail/proxyAddresses per il soft‑match e mantenere ms‑DS‑ConsistencyGuid come sourceAnchor stabile. Con un pilota mirato e la corretta pulizia dei cloud‑only, puoi migrare senza interruzioni di servizio, preservando la continuità di Power BI e degli altri workload.

Appendice: domande originali e risposte rapide

Domanda	Risposta sintetica
Mantenere continuità operativa?	Sì, mediante soft‑match preservi l’ObjectId cloud; i servizi (Power BI, Teams, M365) continuano a funzionare.
Evitare duplicati?	Allinea gli attributi e rimuovi i cloud‑only superflui prima della sync. Usa OU filtering per un roll‑out controllato.
Cambiare UPN può rompere app legacy?	Raramente. Verifica solo le app che usano UPN come chiave/claim. In caso estremo, usa Alternate sign‑in ID.
Procedura passo‑passo?	Segui i sette passi della soluzione consigliata: dominio → suffix → UPN → attributi → Connect → pulizia → test.

Template operativo pronto all’uso

Comunicazione: avvisa gli utenti che l’identità di accesso cambierà da @contoso.local a @contoso.com.
Backup: esporta UPN e proxyAddresses.
Pilota: 10–30 utenti rappresentativi, applicazioni critiche incluse.
Implementazione: cambia UPN, aggiorna attributi, installa Entra Connect, esegui sync iniziale.
Convalida: verifica login a Microsoft 365, Teams, Power BI, posta e app SSO.
Estensione: amplia OU filtrate fino a coprire tutta l’organizzazione.
Stabilizzazione: monitora job di sync, risolvi collisioni su SMTP, documenta le eccezioni.

Risultato atteso

Un solo oggetto per utente, sincronizzato correttamente.
Autenticazione coerente in Azure AD (Microsoft Entra ID) con UPN pubblico.
Continuità garantita per Power BI e tutti i servizi Microsoft 365.