Ora che le aziende stanno adottando il cloud computing come parte del loro modello di business, una grande percentuale sceglie di collegare il proprio ambiente Active Directory on-premise alla sua controparte nel cloud, Azure Active Directory di Microsoft. Quando si estende l'AD on-premises ad Azure AD, si hanno due possibilità di scelta per quanto riguarda le modalità di autenticazione degli utenti on-premises al servizio cloud: la federazione di identità e l'autenticazione diretta con Azure AD. Sebbene l'autenticazione diretta sia tecnicamente il metodo più semplice dei due, richiede l'abilitazione di una funzione nota come sincronizzazione delle password. Credo che la sincronizzazione delle password sia una funzione poco conosciuta che merita maggiori spiegazioni.
Microsoft offre due modi per gestire l'autenticazione ad Azure AD: la federazione di identità o l'autenticazione diretta utilizzando Azure AD stesso. La federazione delle identità con un servizio di federazione come AD FS o PingFederate fornisce il single sign on ad Azure AD reindirizzando gli utenti dal servizio cloud al loro AD locale per l'autenticazione. L'altra opzione, l'autenticazione diretta in Azure AD, richiede che userid e password dell'utente siano memorizzati localmente nel servizio cloud. Per le aziende, questo deve essere fatto con la funzione di sincronizzazione delle password del servizio AD Connect di Microsoft; nessuna terza parte fornisce una funzionalità equivalente.
Che cos'è la sincronizzazione dell'hash della password e perché usarla?
Nella sua forma più semplice, a livello di abbozzo di cocktail-party, la sincronizzazione dell'hash della password (una descrizione più accurata, che spiegherò di seguito) copia la password dell'utente da AD ad Azure AD ogni due minuti. In questo modo gli utenti possono accedere ad Azure AD con la stessa userid e password che utilizzano per l'accesso ad AD. Microsoft chiama questo schema same sign on. Si distingue dal single sign on perché con la sincronizzazione dell'hash della password, agli utenti verrà richiesto di effettuare il login ad Azure AD in aggiunta a qualsiasi login aziendale effettuato.
Perché si dovrebbe usare la sincronizzazione dell'hash della password? Principalmente perché è più semplice da implementare rispetto a un servizio di federazione. Microsoft aveva bisogno di fornire un modo semplice per integrare gli utenti di AD on-premises con Azure AD, e la sincronizzazione dell'hash della password lo fa senza la necessità di un servizio di federazione ad alta disponibilità su più server.
La soluzione più semplice ha dimostrato di essere popolare: circa il 50% delle organizzazioni che sincronizzano con Azure AD utilizza la sincronizzazione con hash password. Di questo 50%, la metà sono organizzazioni di piccole e medie dimensioni. La sincronizzazione dell'hash della password offre a queste organizzazioni un percorso agevole per passare a un'infrastruttura IT cloud-first o cloud-only, perché gli utenti si autenticano già direttamente con il servizio Azure AD.
Un altro vantaggio della sincronizzazione dell'hash della password è che, a differenza della federazione, non dipende da un servizio di federazione esterno per elaborare le autenticazioni. In effetti, Microsoft offre la sincronizzazione dell'hash della password in aggiunta alla federazione, in modo da poterla utilizzare come ripiego in caso di interruzione del servizio di federazione.
Quanto è sicura la sincronizzazione dell'hash delle password?
Si noti che questa funzione viene descritta come sincronizzazione dell 'hash della password, non come sincronizzazione della password. È una distinzione importante. Le password in chiaro non vengono sincronizzate tra AD DS e Azure AD. Non solo non è una buona idea, ma non è nemmeno tecnicamente possibile perché Active Directory non dispone delle password in chiaro. Quando un utente crea o aggiorna la propria password in AD, questa viene memorizzata come hash MD5 unidirezionale sui DC del dominio. Questo hash viene sincronizzato con Azure AD e memorizzato nell'archivio delle credenziali del servizio.
Come funziona esattamente? Ho raccolto i seguenti passaggi dal post di Alex Simon su AAD Password Sync, Encryption, and FIPS Compliance e da alcune altre fonti:
- Le password degli utenti sono memorizzate come hash non reversibile nei controller di dominio (DC) di Windows Server Active Directory. Quando l'agente di sincronizzazione delle password su AD Connect tenta di sincronizzare l'hash della password, il DC cripta l'hash. La crittografia viene eseguita con una chiave derivata dalla chiave di sessione RPC mediante salatura. La derivazione della chiave è la seguente [dove SaltedEncryptionKey = MD5 (RPC session Key, 128 bit random salt)]. Il DC passa il sale anche all'agente di sincronizzazione utilizzando il protocollo di replica.
- L'hash della password originale viene replicato (utilizzando il protocollo di replica del DC) dal DC al Password Sync Agent.
- L'agente di sincronizzazione delle password decifra l'hash crittografato ricavando la chiave come descritto sopra. L'agente di sincronizzazione delle password utilizza MD5 per eseguire la derivazione della chiave, in quanto la derivazione deve essere identica a quella eseguita dal DC (quando ha crittografato i dati). Inoltre, MD5 è il livello più alto disponibile per questa azione nel protocollo di replica dei DC delle implementazioni esistenti di Windows Server Active directory.
- Una volta effettuata la decodifica, l'agente di sincronizzazione prende l'hash della password originale risultante e lo ri-incide in un hash SHA256 utilizzando l'algoritmo di derivazione delle chiavi PKDF2, definito in RFC 2898.
- L'Agente di sincronizzazione password sincronizza quindi l'hash della password con hash SHA256 attraverso il filo (un relay Service Bus crittografato dedicato al tenant Azure AD) con Azure AD.
- Una volta che la copia con hash SHA256 della password originale raggiunge Azure AD, Azure AD cripta l'hash con l'algoritmo AES prima di memorizzarlo nel database del cloud.
L'unica cosa che attraversa il filo nel percorso verso Azure AD è una copia con hash SHA256 dell'hash della password originale. L'uso di MD5 da parte dell'agente di sincronizzazione delle password è strettamente legato alla compatibilità del protocollo di replica con il DC e viene utilizzato solo tra il DC e l'agente di sincronizzazione delle password.
Svantaggi della sincronizzazione dell'hash della password
Dal punto di vista dell'utente, lo svantaggio più evidente è che l'utente deve inserire le proprie credenziali aziendali una seconda volta, indipendentemente dal fatto che sia connesso alla rete aziendale o a una rete pubblica. Tuttavia, è possibile ridurre questi accessi selezionando la casella di controllo "Keep me signed in" (KMSI). Selezionando questa opzione si imposta un cookie di sessione che bypassa l'autenticazione per un breve periodo. L'amministratore di Azure AD può attivare o disattivare il comportamento di KMSI.
Dal punto di vista del professionista dell'identità, il problema della sincronizzazione dell'hash della password è che la password viene distribuita in più luoghi per l'autenticazione. Al contrario, la federazione reindirizza tutte le richieste di autenticazione al fornitore di identità. Microsoft si è impegnata a fondo per garantire la sicurezza del processo, ma è lecito porsi domande sul ciclo di vita della password.
Quando è necessario utilizzare la sincronizzazione dell'hash della password?
Esiste un caso d'uso in cui è necessario utilizzare la sincronizzazione dell'hash della password: se si sceglie di implementare Azure AD Domain Services. Questa funzione crea un controller di dominio come servizio che le applicazioni Azure (come le macchine virtuali che eseguono applicazioni dipendenti da AD) possono utilizzare. Affinché questi DC siano funzionalmente equivalenti ai DC on-premises, tuttavia, devono avere gli hash delle password degli utenti e quindi richiedono la sincronizzazione degli hash delle password per essere inseriti in Azure.
La sincronizzazione dell'hash delle password è una soluzione popolare per integrare le identità on-premises con Azure AD. Non è elegante come la federazione di identità, ma è più semplice. Come per ogni decisione di progettazione, assicuratevi di aver analizzato i punti di forza e di debolezza di questa soluzione e di come si applica alla vostra situazione.
