Perché l’identità ibrida

Quasi ogni organizzazione che adotta il cloud parte da un dominio Active Directory (AD DS) on-premises già esistente. L’obiettivo dell’identità ibrida è dare agli utenti una sola identità con cui accedere sia alle risorse locali sia a quelle cloud (Microsoft 365, app SaaS, Azure), senza gestire due account separati. Il ponte che rende possibile tutto questo è Microsoft Entra Connect Sync, l’agent che sincronizza oggetti e attributi da AD DS verso Microsoft Entra ID.

Entra Connect Sync e l’object matching

Entra Connect Sync gira su un server on-premises ed esegue cicli di sincronizzazione periodici (default ogni 30 minuti) che proiettano utenti, gruppi e contatti nel tenant cloud. Due concetti sono centrali per l’esame:

  • Source Anchor (immutableId): l’attributo immutabile che lega univocamente un oggetto on-prem al suo corrispondente cloud. Dalle versioni recenti si usa ms-DS-ConsistencyGuid, che sopravvive a migrazioni e ricostruzioni del server di sync.
  • Object matching (soft match / hard match): quando un utente cloud esiste già, Connect evita di creare un duplicato abbinandolo all’oggetto on-prem. Il soft match avviene tramite corrispondenza dell’attributo userPrincipalName o del proxyAddress (SMTP primario); l’hard match avviene tramite immutableId. Prerequisito pratico: i UPN devono usare un dominio verificato e instradabile (evitare il suffisso .local), altrimenti gli utenti finiscono con UPN onmicrosoft.com.

Seamless SSO

Seamless Single Sign-On (Seamless SSO) consente agli utenti su dispositivi domain-joined e connessi alla rete aziendale di autenticarsi automaticamente, senza reinserire la password. Tecnicamente crea un account computer AZUREADSSOACC in AD e sfrutta Kerberos. È un’opzione, non un metodo di autenticazione a sé: si abbina a Password Hash Sync o a Pass-through Authentication, non serve con la federazione (che ha già il proprio SSO).

I tre metodi di sign-in ibrido

La scelta del metodo di autenticazione è la decisione architetturale più tipica di questo dominio d’esame.

Password Hash Sync (PHS)

Con PHS, Entra Connect sincronizza nel cloud un hash dell’hash della password (non la password in chiaro, né l’hash NTLM utilizzabile). L’autenticazione avviene interamente in Entra ID.

  • Vantaggi: massima semplicità, nessun componente aggiuntivo, alta disponibilità naturale. Se l’infrastruttura on-prem è offline, il login cloud continua a funzionare.
  • Punto chiave: PHS è prerequisito per il rilevamento delle credenziali compromesse (leaked credential detection) in Entra ID Protection. Senza gli hash nel cloud, il servizio non può confrontarli con le credenziali trapelate.

Pass-through Authentication (PTA)

Con PTA, la password non viene sincronizzata: Entra ID inoltra la richiesta a un PTA agent on-prem che la valida in tempo reale contro AD DS.

  • Adatto a chi ha requisiti che impongono che la validazione password resti on-premises (policy locali, orari di accesso).
  • Richiede almeno due agent per l’alta disponibilità: se tutti gli agent sono offline, gli utenti non possono autenticarsi.
  • Best practice: abilitare anche PHS come backup, così un guasto agli agent non blocca i login e resta attivo il leaked credential detection.

Federazione (AD FS)

La federazione delega l’autenticazione a un provider esterno come AD FS. Va scelta solo per requisiti che gli altri due non coprono: autenticazione con smart card/certificati, regole di rilascio claim complesse, o integrazione con un IdP di terze parti esistente. Comporta la maggiore complessità operativa (server AD FS + Web Application Proxy, certificati, alta disponibilità).

Trappole tipiche d’esame

  • Scenario: l’azienda vuole abilitare il rilevamento delle credenziali compromesse in Entra ID Protection ma usa PTA puro. → Risposta: abilitare Password Hash Sync, che è il prerequisito del leaked credential detection.
  • Scenario: requisiti “solo SSO cloud, minima infrastruttura, resilienza a outage on-prem”. → Risposta: Password Hash Sync (+ Seamless SSO), non federazione né PTA.
  • Scenario: si propone AD FS per un semplice sign-in Microsoft 365. → Risposta sbagliata: la federazione è overkill; scegliere PHS a meno che non servano smart card/claim complessi.
  • Scenario: si sceglie PTA con un solo agent. → Risposta: distribuire agent multipli (e abilitare PHS come fallback) per evitare single point of failure.
  • Scenario: dopo aver ricostruito il server di sync compaiono account duplicati. → Risposta: garantire lo stesso Source Anchor (ms-DS-ConsistencyGuid) per riabilitare l’hard match e prevenire i duplicati.