Progettare l’identità ibrida significa decidere dove vengono validate le credenziali e quanta dipendenza dall’infrastruttura on-premise l’organizzazione è disposta ad accettare. In AZ-305 la domanda tipica parte da un requisito (controllo delle credenziali, compliance, resilienza) e chiede la soluzione con il miglior trade-off. Il framework di riferimento è l’Azure Well-Architected Framework: qui pesano soprattutto i pilastri Reliability, Security e Operational Excellence.

I tre metodi di autenticazione

Password Hash Synchronization (PHS)

Un hash dell’hash della password viene sincronizzato in Microsoft Entra ID; l’autenticazione avviene interamente nel cloud. È la scelta di default e la più resiliente: se cadono i domain controller on-prem o la VPN, gli utenti continuano ad autenticarsi. Abilita inoltre leaked credential detection di Entra ID Protection e supporta lo scenario di disaster recovery anche per PTA/federation. Trade-off: le credenziali (in forma derivata) risiedono nel cloud, cosa che alcune policy vietano.

Pass-through Authentication (PTA)

La validazione avviene sui domain controller on-prem tramite agent leggeri; nessun hash lascia il perimetro. Adatta a chi ha requisiti di controllo credenziali on-prem o policy password immediate (scadenze, disable account) senza AD FS. Trade-off critico: introduce una dipendenza dall’infrastruttura on-prem. Un singolo agent è un single point of failure — vanno installati almeno 2-3 agent su host separati per garantire alta disponibilità.

Federation con AD FS (o provider terzo)

L’autenticazione è delegata a un’infrastruttura di federazione on-prem. Si sceglie solo quando servono requisiti che PHS/PTA non coprono: smart card / certificati, MFA di terze parti a livello di STS, restrizioni di sign-in a livello di rete on-prem, o integrazione con IdP esistenti. Trade-off pesante: è l’opzione con maggiore complessità, superficie di attacco e costo operativo, e richiede farm ridondanti, WAP nella DMZ e certificati da gestire. La tendenza 2026 è defederare verso PHS/PTA ove possibile.

Seamless SSO è ortogonale: fornisce il login trasparente da dispositivi domain-joined per PHS e PTA (con AD FS l’SSO è nativo). Non è un metodo di autenticazione a sé.

Regola di scelta rapida

  • Nessun vincolo particolare → PHS + Seamless SSO (default resiliente).
  • Le credenziali non devono risiedere nel cloud / policy on-prem immediate → PTA + Seamless SSO con agent ridondanti.
  • Smart card, MFA di terze parti a livello STS, controllo di rete on-prem → AD FS, con PHS abilitato come fallback di resilienza.

Entra Connect Sync vs Entra Cloud Sync

Entrambi sincronizzano oggetti verso Entra ID, ma con architetture diverse.

  • Entra Connect Sync: server dedicato on-prem con SQL locale, motore di sincronizzazione completo. Necessario per scenari avanzati: device/Exchange hybrid writeback, group writeback, regole di trasformazione custom, filtri OU complessi, pass-through verso una sola foresta con topologie particolari.
  • Entra Cloud Sync: agent leggeri (gli stessi del provisioning), configurazione cloud-managed, alta disponibilità nativa con più agent, ideale per multi-foreste disconnesse e footprint minimo. Non copre ancora tutti gli scenari avanzati di Connect Sync.

Criterio di migrazione: partire da Cloud Sync per i nuovi deployment e le foreste semplici; migrare da Connect Sync a Cloud Sync quando i requisiti rientrano nelle capability supportate, sfruttando la coesistenza (i due strumenti possono gestire oggetti diversi in parallelo durante la transizione). Restare su Connect Sync solo finché serve una feature non ancora disponibile in Cloud Sync.

Trappole tipiche d’esame

  • “Se cade il collegamento on-prem gli utenti devono comunque autenticarsi” → scegli PHS. Con PTA o AD FS puro l’autenticazione si ferma; l’unico modo per garantire continuità è avere PHS abilitato come backup.
  • “Requisito: credenziali validate on-prem, ma serve alta disponibilità” → PTA con ≥2 agent ridondanti su server distinti. Un solo agent = single point of failure che l’esame vuole farti riconoscere.
  • “Serve MFA di terze parti / smart card / restrizioni di rete a livello di autenticazione” → AD FS (o federation), non PHS/PTA. Ma abbina sempre PHS per il disaster recovery.
  • Assunzioni errate sul soft-match: il soft-match aggancia un oggetto cloud a uno on-prem via primary SMTP / userPrincipalName, non arbitrariamente. Se gli attributi non combaciano crei utenti duplicati; per collegare esplicitamente oggetti esistenti usa l’hard-match con ImmutableID (ms-DS-ConsistencyGuid). Non dare per scontato che la sync “riconosca” gli utenti già presenti.
  • “Ridurre dipendenza da infrastruttura on-prem e superficie d’attacco” → defederare da AD FS verso PHS/PTA; scegliere Connect Sync solo se una feature lo impone, altrimenti Cloud Sync per HA nativa e gestione cloud.