L’identità ibrida è il ponte fra Active Directory Domain Services on-premises e Microsoft Entra ID. In MS-102 non ti viene chiesto di installare il tool, ma di scegliere il metodo di autenticazione giusto per un requisito dato e di sapere cosa succede quando qualcosa si rompe.

I tre metodi di autenticazione

Requisito PHS PTA Federazione (AD FS)
Dipendenza da infrastruttura on-prem per il sign-in Nessuna Alta (agent + DC raggiungibili) Alta (farm AD FS + WAP)
Alta disponibilità Nativa (servizio cloud) Serve un secondo/terzo agent Serve farm multi-nodo + load balancer
Leaked credential detection (Entra ID Protection) Sì No (se non si abilita PHS) No (se non si abilita PHS)
Password stored in cloud Hash dell’hash No No
Sign-in hours / smart card / MFA di terze parti applicati a livello on-prem No Sì (sign-in hours) Sì (scenario completo)

Password Hash Sync (PHS) sincronizza un hash SHA256 dell’hash NT ogni 2 minuti, indipendentemente dal ciclo di sincronizzazione delle directory. È il metodo di default consigliato: nessun server esposto, sopravvive a un’interruzione della connettività on-prem e abilita il rilevamento delle credenziali compromesse.

Pass-through Authentication (PTA) valida la password direttamente contro un domain controller tramite agent leggeri. La password non lascia mai l’ambiente on-prem, ma se gli agent o i DC sono giù, nessuno si autentica. Servono almeno 3 agent su macchine distinte per l’alta disponibilità.

Federazione serve quando c’è un requisito che solo AD FS soddisfa: autenticazione con smart card/certificato, MFA di terze parti a livello di STS, o claim rules personalizzate.

Seamless SSO e resilienza

Seamless SSO (Desktop SSO) si abilita insieme a PHS o PTA — non con la federazione, che ha il proprio meccanismo di SSO. Crea l’oggetto computer AZUREADSSOACC in AD; la sua chiave Kerberos va ruotata almeno ogni 30 giorni. I client devono avere https://autologon.microsoftazuread-sso.com nella zona Intranet, distribuito via GPO.

Il pattern di resilienza chiave: con PTA o federazione, abilita comunque PHS come metodo di backup. In caso di outage on-prem si commuta l’autenticazione al cloud, e nel frattempo Entra ID Protection può valutare le credenziali compromesse.

Filtri di sincronizzazione

  • Filtro per dominio — esclude interi domini della foresta.
  • Filtro per OU (raccomandato) — configurabile dal wizard di Entra Connect, è il metodo più prevedibile e riconfigurabile senza toccare le regole di sync.
  • Filtro per gruppo — supportato solo per pilot/deployment iniziale, non in produzione.
  • Filtro per attributo — richiede modifica delle sync rule tramite Synchronization Rules Editor.

Attenzione: restringere un filtro fa uscire dallo scope gli oggetti già sincronizzati, che vengono quindi eliminati nel cloud (recuperabili dal cestino per 30 giorni).

Staging server e comandi operativi

Un staging server importa e sincronizza ma non esporta verso Entra ID né verso AD: serve per disaster recovery e per validare modifiche di configurazione prima di applicarle. Si promuove disattivando la staging mode dal wizard.

Start-ADSyncSyncCycle -PolicyType Delta     # ciclo delta on demand
Start-ADSyncSyncCycle -PolicyType Initial   # full sync dopo cambi di filtro/regole
Get-ADSyncScheduler                         # verifica intervallo (default 30 min) e staging mode
Set-ADSyncScheduler -SyncCycleEnabled $false
Get-ADSyncConnectorRunStatus

Un cambio di filtro, di regola di sincronizzazione o di schema richiede un Initial (full) sync, non un Delta.

Trappole tipiche d’esame

  • Scenario: PTA in produzione, si vuole garantire il sign-in anche se il datacenter on-prem è offline e attivare il rilevamento di credenziali compromesse → abilitare Password Hash Sync come fallback; aggiungere altri agent PTA risolve solo la ridondanza degli agent, non l’outage completo né la leaked credential detection.
  • Scenario: il dominio AD è contoso.local e gli utenti compaiono in Entra ID come user@tenant.onmicrosoft.com → il UPN suffix deve essere routable e verificato nel tenant: aggiungere contoso.com come suffisso alternativo in Active Directory Domains and Trusts e riassegnarlo agli utenti, poi risincronizzare.
  • Scenario: dopo la prima sincronizzazione esistono utenti cloud duplicati → il soft match avviene su primary SMTP address (proxyAddresses) o UPN; se l’indirizzo cloud non coincide, l’oggetto viene creato ex novo. Rimedio: allineare il proxyAddress on-prem oppure eseguire un hard match valorizzando l’ImmutableID/ms-DS-ConsistencyGuid sull’oggetto cloud.
  • Scenario: un admin prova a cambiare job title o UPN di un utente sincronizzato dall’interfaccia Entra e il campo è in sola lettura → gli attributi di un oggetto sincronizzato si modificano solo on-premises. Restano gestibili nel cloud: assegnazione licenze, ruoli, metodi MFA e attributi cloud-only.
  • Scenario: rimossa una OU dallo scope di sincronizzazione, gli account cloud spariscono → comportamento atteso; il filtro definisce l’insieme autoritativo e l’esclusione produce una cancellazione, non un “orfano” gestibile nel cloud.