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 non si è parlato molto, tuttavia, è quella che praticamente tutti i miei clienti aziendali richiedono: L'opzione del server di staging Azure AD Connect. Per comprendere questa opzione, esaminiamo innanzitutto la situazione che è stata progettata per mitigare.
Come funziona la sincronizzazione delle identità Microsoft
Questa evoluzione delle utility di sincronizzazione - DirSync, il suo successore AADSync e infine AD Connect - utilizza una versione ridotta del servizio di metadirectory di Microsoft, variamente denominato MIIS, ILM, FIM e, da qualche mese, Microsoft Identity Manager (MIM). Questi servizi di metadiretorio dispongono di connettori sia per AD DS che per Azure AD, per estrarre gli attributi negli spazi dei connettori. Una serie di regole di sincronizzazione determina se questi attributi vengono aggiunti in un metaverso che contiene l'unione degli attributi delle identità on-premises e degli attributi 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 contenere gli spazi dei connettori e il metaverso. Non c'è tolleranza agli errori o ridondanza in questo database on-server e il clustering non è consigliato. E se state pensando: "Ripristinerò il database dai backup che ho fatto", nemmeno questo è supportato. In pratica, se il server muore, bisogna disinstallare e reinstallare il servizio di sincronizzazione o ripristinare l'intero server dai backup.
La situazione non è così grave come sembra. Microsoft afferma giustamente che, sebbene la sincronizzazione sia certamente un servizio mission critical, non è un servizio particolarmente sensibile al tempo; l'intervallo di sincronizzazione predefinito e consigliato è di tre ore. Ciò significa che, sebbene possano essere necessarie alcune ore per ricostruire il servizio di sincronizzazione in caso di guasto, al massimo si perderà un ciclo di sincronizzazione. I centri IT aziendali, tuttavia, non amano le zone d'ombra nei tempi di ripristino dei sistemi di produzione. Nella maggior parte delle grandi aziende, se si tratta di un sistema di grande importanza, deve avere un qualche tipo di tolleranza ai guasti o di disponibilità avanzata. Ma sei serio? è un commento che ho ricevuto più di una volta quando un'azienda stava valutando le capacità di alta disponibilità di DirSync o AADSync.
Come funziona l'opzione del server di staging
L'opzione del server di staging è stata sviluppata per risolvere questa lacuna. Sebbene non si tratti di una vera e propria alta disponibilità, l'implementazione del server di staging consente di riprendere la sincronizzazione dell'identità entro pochi minuti (una volta deciso il fail over).
Per impostare un server di staging (Figura 2), si esegue una configurazione di Azure AD Connect identica a quella del server AD Connect primario, con una sola eccezione: Nell'ultimo passaggio, si seleziona l'opzione del server di staging. Questo impedisce che i risultati della sincronizzazione sviluppati nel servizio del server di staging vengano scritti su Azure AD o su AD DS. Ciò significa anche che la sincronizzazione del writeback e dell'hash delle password è disabilitata, perché la prima richiede modifiche scritte in AD DS, mentre la seconda richiede modifiche 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 del server di staging (e il writeback della password o la sincronizzazione degli hash, se la si utilizza). In questo modo si abilitano gli aggiornamenti ad Azure AD e AD DS. Ovviamente bisogna fare attenzione che solo un server AD Connect alla volta sia completamente abilitato!
L'opzione del server di staging in AD Connect è una nuova funzionalità che sarà accolta con favore dalle grandi aziende. Offre un tempo di ripristino del servizio molto più breve rispetto ai suoi predecessori ed è semplice da implementare, senza particolari requisiti hardware o software. Sono sicuro che diventerà una pratica di distribuzione standard per molte aziende.
