Il problema: come portare le identità on-premises verso il cloud

In uno scenario di hybrid identity gli oggetti (utenti, gruppi, contatti) vivono in Active Directory Domain Services (AD DS) on-premises, ma l’autenticazione e l’autorizzazione ai servizi cloud avvengono in Microsoft Entra ID. Serve quindi un motore di sincronizzazione. Da SC-300 devi saper scegliere tra i due motori supportati: Microsoft Entra Connect Sync (il motore “classico”, installato on-premises) e Microsoft Entra Cloud Sync (il motore leggero gestito dal cloud). Non è mai “quale è migliore”, ma “quale copre i requisiti dello scenario”.

Microsoft Entra Cloud Sync

Cloud Sync si basa su un provisioning agent leggero installato su un server membro del dominio. La configurazione (scoping, attribute mapping, trasformazioni) risiede nel cloud ed è gestita dal portale Entra: l’agent riceve le istruzioni da Entra ID, riducendo footprint e manutenzione on-premises.

Punti di forza rilevanti all’esame:

  • Foreste multiple disconnesse: Cloud Sync collega più foreste AD non trusted allo stesso tenant senza richiedere connettività tra le foreste. Ideale per fusioni/acquisizioni.
  • Alta disponibilità nativa: puoi installare più agent che lavorano in modo attivo. Se un agent cade, gli altri continuano — nessun single point of failure, senza cluster o staging server.
  • Requisiti semplici: supporta password hash synchronization (PHS), SSPR password writeback, group provisioning verso Entra ID, filtri di scoping per OU o per attributo, e attribute mapping/trasformazioni di base.
  • Aggiornamento automatico dell’agent e configurazione centralizzata nel cloud.

Microsoft Entra Connect Sync

Connect Sync è il motore full-featured: un sync engine completo installato on-premises, con regole di sincronizzazione personalizzabili (Synchronization Rules Editor), staging server per la resilienza e supporto agli scenari avanzati che Cloud Sync non copre.

Serve ancora Connect Sync quando lo scenario richiede:

  • Device synchronization → Hybrid Microsoft Entra Join basato su sync richiede Connect Sync (Cloud Sync non sincronizza oggetti device).
  • Pass-through Authentication (PTA) come metodo di autenticazione (Cloud Sync supporta PHS, non PTA).
  • Exchange hybrid writeback (deployment Exchange ibrido con attribute writeback).
  • Merge di identità dello stesso utente tra più foreste in un unico oggetto (GAL sync / matching cross-forest).
  • Regole di sincronizzazione avanzate e filtri complessi, group writeback di gruppi Microsoft 365 verso AD, o gruppi molto grandi (oltre circa 50.000 membri).

Password Hash Sync: un chiarimento

PHS non è “meno sicuro” né esclusivo di un motore: entrambi i motori lo supportano. La scelta del motore non cambia il metodo di autenticazione, ma cambia quali metodi sono disponibili. Se il requisito è PTA o federazione con AD FS più device writeback, Cloud Sync da solo non basta.

Coesistenza

Cloud Sync e Connect Sync possono coesistere nello stesso tenant, tipico scenario di migrazione graduale o di gestione di foreste diverse con motori diversi. La regola d’oro: un singolo oggetto non deve essere sincronizzato da entrambi i motori. Puoi ripartire il lavoro per foresta o per OU, ma le aree di scoping non devono sovrapporsi sullo stesso oggetto, pena conflitti e comportamenti imprevedibili.

Trappole tipiche d’esame

  • Scenario: più foreste AD disconnesse, requisiti semplici (solo PHS), serve alta disponibilità con minimo footprint on-premises → Cloud Sync con più agent, non Connect Sync con staging server.
  • Scenario: l’azienda richiede Hybrid Microsoft Entra Join basato su sincronizzazione dei device → serve Connect Sync; Cloud Sync non sincronizza i device (distrattore classico: “usa Cloud Sync per l’HA”).
  • Scenario: si vuole PTA come autenticazione ibrida → serve Connect Sync; se la domanda ammette PHS, allora Cloud Sync è sufficiente. Leggi bene il metodo di autenticazione richiesto.
  • Scenario: migrazione da Connect Sync a Cloud Sync sulla stessa foresta → ripartisci per OU e non far gestire lo stesso oggetto da entrambi; la coesistenza è supportata solo con scoping non sovrapposto.
  • Scenario: Exchange hybrid writeback o merge dello stesso utente da due foreste → Connect Sync obbligatorio; sono limiti espliciti di Cloud Sync.