Microsoft continua a lavorare su un punto dolente della sua strategia di identità ibrida: La sfida di implementare il suo ponte di identità tra Active Directory Domain Services (AD DS) in sede e Azure Active Directory nel cloud. Questo ponte è costituito da AD FS per la federazione e da una serie di utility, che culminano in Azure AD Connect, per la sincronizzazione delle identità. Azure AD Connect è stato recentemente reso generalmente disponibile e rende l'esperienza di aggancio di AD DS on-premises (e di altri tipi di database di identità come SQL Server o LDAP) ad Azure AD più semplice rispetto ai suoi predecessori DirSync e Azure AD Sync.
Le nuove funzionalità di AD Connect
AD Connect (per saperne di più qui) è un'utility di configurazione che semplifica l'impostazione della sincronizzazione delle identità tra un breve elenco di fonti di identità popolari (compresi ovviamente i servizi di dominio di Active Directory) e, facoltativamente, il single sign on con AD FS. Semplifica notevolmente il processo di configurazione e fornisce anche nuove funzionalità, come il writeback degli attributi relativi al dispositivo da Azure AD ad AD DS.
Una nuova funzionalità di cui, tuttavia, si è parlato poco è proprio quella richiesta praticamente da tutti i miei clienti aziendali: l’opzione del server di staging di Azure AD Connect. Per comprendere questa opzione, esaminiamo innanzitutto la situazione che essa è stata progettata per risolvere.
Come funziona la sincronizzazione delle identità Microsoft
Questa evoluzione delle utilità di sincronizzazione – DirSync, il suo successore AADSync e, infine, AD Connect – utilizza una versione ridotta del servizio di metadirectory di Microsoft, denominato in vari modi: MIIS, ILM, FIM e, da alcuni mesi, Microsoft Identity Manager (MIM). Questi servizi di metadirectory dispongono di connettori sia per AD DS che per Azure AD, che consentono di importare gli attributi negli spazi dei connettori. Una serie di regole di sincronizzazione determina se tali attributi vengono aggiunti a un metaverso che contiene l’unione sia degli attributi di identità locali che di quelli di Azure AD. Infine, le regole di sincronizzazione in uscita determinano quali attributi vengono scritti in Azure AD.
Figura 1: Architettura del servizio AD Connect (Immagine per gentile concessione di Microsoft)
Ciò richiede un server con connettori configurati, regole definite e un motore di database (SQL Server Express o SQL Server completo) per ospitare gli spazi dei connettori e il metaverso. In questo database sul server non è integrata alcuna tolleranza ai guasti né ridondanza, e il clustering non è consigliato. E se state pensando: «Basterà ripristinare il database dai backup che eseguo», sappiate che nemmeno questa opzione è supportata. In sostanza, se il server smette di funzionare, dovrete disinstallare e reinstallare il servizio di sincronizzazione oppure ripristinare l’intero server dai backup.
La situazione non è poi così grave come sembra. Microsoft afferma giustamente che, sebbene la sincronizzazione sia certamente un servizio mission-critical, non è un servizio particolarmente sensibile al fattore tempo; l’intervallo di sincronizzazione predefinito e consigliato è di tre ore. Ciò significa che, sebbene possa essere necessario qualche ora per ripristinare il servizio di sincronizzazione in caso di guasto, al massimo probabilmente si perderà un solo ciclo di sincronizzazione. I reparti IT aziendali, tuttavia, non gradiscono le zone d’ombra nei tempi di ripristino dei propri sistemi di produzione. Nella maggior parte delle grandi aziende, se un sistema è considerato di alta importanza, deve disporre di una qualche forma di tolleranza ai guasti o di disponibilità avanzata integrata. «Ma state scherzando?» è un commento che ho ricevuto più di una volta quando un’azienda stava valutando le funzionalità di alta disponibilità di DirSync o AADSync.
Come funziona l'opzione del server di staging
L'opzione del server di staging è stata sviluppata proprio per ovviare a questa lacuna. Sebbene non si tratti di vera e propria alta disponibilità, l'implementazione del server di staging consentirà di riprendere la sincronizzazione delle identità nel giro di pochi minuti (una volta deciso di effettuare il failover su di esso).
Per configurare un server di staging (Figura 2), occorre seguire la stessa procedura di configurazione di Azure AD Connect utilizzata per il server AD Connect primario, con un’unica eccezione: nell’ultimo passaggio, occorre selezionare l’opzione relativa al server di staging. Ciò impedisce che i risultati della sincronizzazione generati dal servizio del server di staging vengano scritti in Azure AD o riportati in AD DS. Ciò significa anche che il writeback delle password e la sincronizzazione degli hash delle password sono disabilitati, poiché il primo richiede che le modifiche vengano scritte in AD DS, mentre il secondo richiede che le modifiche vengano scritte in Azure AD.
Figura 2: Architettura AD Connect con Staging Server
Ripristino di un guasto di AD Connect
In caso di guasto del server AD Connect primario, è sufficiente eseguire nuovamente la procedura guidata di configurazione di AD Connect e deselezionare l'opzione relativa al server di staging (nonché il writeback delle password o la sincronizzazione degli hash, se utilizzati). In questo modo si abilitano gli aggiornamenti ad Azure AD e AD DS. Ovviamente è necessario assicurarsi che sia abilitato completamente un solo server AD Connect alla volta!
L'opzione "server di staging" in AD Connect è una nuova funzionalità che sarà accolta con favore dalle grandi imprese. Garantisce tempi di ripristino del servizio molto più brevi rispetto alle versioni precedenti ed è semplice da implementare, senza requisiti hardware o software particolari. Sono certo che diventerà una pratica di implementazione standard per molte aziende.
