La migrazione di Active Directory verso Microsoft Azure richiede un'analisi approfondita dell'architettura di autenticazione, delle dipendenze applicative e dei servizi infrastrutturali che utilizzano il dominio aziendale. Active Directory Domain Services (AD DS) è basato su un modello di directory che gestisce utenti, gruppi, computer, criteri di sicurezza e autenticazione Kerberos e NTLM. Microsoft Entra ID, precedentemente denominato Azure Active Directory, è invece un servizio di identità cloud progettato per l'autenticazione alle applicazioni, l'accesso condizionale e l'integrazione con Microsoft 365 e altri servizi cloud.
Questa distinzione è fondamentale perché migrare Active Directory su Azure non significa semplicemente trasferire il dominio esistente nel cloud. La strategia corretta dipende dai requisiti dell'organizzazione: mantenere Active Directory Domain Services su macchine virtuali Azure, sincronizzare le identità locali con Microsoft Entra ID oppure riprogettare l'autenticazione adottando servizi cloud-native. Le tre soluzioni rispondono a esigenze differenti e possono anche coesistere durante una fase di transizione.
Prima di intervenire è necessario censire i domain controller, i livelli funzionali del dominio e della foresta, le zone DNS, le relazioni di trust, le Group Policy e le applicazioni che utilizzano LDAP, Kerberos o NTLM. Devono essere individuati anche i servizi che dipendono da account di dominio, come file server, database, sistemi di stampa, applicazioni gestionali e attività pianificate. Una migrazione priva di questa mappatura può compromettere servizi che, pur non essendo direttamente collegati alla directory, dipendono dall'autenticazione centralizzata.
Active Directory su Azure o Microsoft Entra ID: quale soluzione scegliere
La prima decisione riguarda il modello di destinazione. Se l'azienda dispone di applicazioni che richiedono un dominio Windows tradizionale, criteri Group Policy, autenticazione Kerberos o LDAP, può essere necessario mantenere AD DS e trasferire i domain controller su macchine virtuali Azure. In questo scenario, Azure ospita l'infrastruttura di dominio, ma i servizi Active Directory continuano a funzionare secondo il modello tradizionale.
Se l'obiettivo è gestire l'accesso a Microsoft 365, applicazioni SaaS e risorse integrate con l'identità cloud, Microsoft Entra ID può diventare il principale punto di autenticazione. Tuttavia, Entra ID non è un domain controller tradizionale e non sostituisce direttamente tutte le funzionalità di AD DS. Le applicazioni che richiedono LDAP, join al dominio tradizionale o specifici meccanismi Kerberos devono essere analizzate separatamente.
Un'altra possibilità è utilizzare Microsoft Entra Domain Services, servizio gestito che fornisce funzionalità di dominio come join dei dispositivi, LDAP, Kerberos e NTLM per scenari compatibili, senza richiedere all'azienda di amministrare direttamente i domain controller. Non offre però tutte le capacità amministrative di un'installazione AD DS autonoma e presenta vincoli specifici sulla gestione del dominio, delle unità organizzative e dei privilegi. Prima di sceglierlo è quindi necessario verificare la compatibilità delle applicazioni e i requisiti amministrativi.
Migrare i domain controller su macchine virtuali Azure
Quando è necessario conservare Active Directory Domain Services, una strategia consiste nell'estendere il dominio esistente ad Azure e promuovere nuove macchine virtuali come domain controller aggiuntivi. Questa soluzione consente di trasferire progressivamente i servizi mantenendo il dominio, gli identificativi degli oggetti e la struttura organizzativa, evitando una ricostruzione completa delle identità.
La rete deve essere progettata prima della creazione dei domain controller. In genere si configura una Azure Virtual Network con subnet dedicate, collegata alla rete aziendale mediante VPN site-to-site oppure ExpressRoute, se richiesto dall'architettura. Il collegamento deve garantire connettività stabile tra i domain controller locali e quelli ospitati nel cloud, con instradamento corretto e regole di sicurezza che consentano esclusivamente il traffico necessario.
Le macchine virtuali devono utilizzare indirizzi IP privati adeguatamente pianificati e una configurazione DNS coerente con il dominio Active Directory. I domain controller devono poter risolvere i record DNS necessari alla localizzazione dei servizi LDAP, Kerberos e Global Catalog. La configurazione delle subnet Azure e delle relative opzioni DNS deve essere coordinata con le impostazioni dei sistemi operativi e con la pianificazione dei riavvii, perché le modifiche alle impostazioni DNS della rete possono richiedere il rinnovo della configurazione dei client o il riavvio delle VM interessate.
Dopo aver verificato la connettività, si installa il ruolo Active Directory Domain Services sulle nuove macchine Windows Server e si procede alla promozione a domain controller aggiuntivo del dominio esistente. Durante questa fase, Active Directory replica directory e partizioni DNS secondo la topologia configurata. È necessario verificare la corretta replica degli oggetti, la disponibilità del Global Catalog e la registrazione dei record DNS prima di spostare ulteriori servizi.
Una volta completata la replica, occorre controllare la salute della directory con strumenti diagnostici come dcdiag e repadmin. Il primo permette di individuare anomalie nella configurazione e nei servizi del domain controller, mentre il secondo consente di analizzare lo stato della replica tra i controller di dominio. Eventuali errori di autenticazione, risoluzione DNS o sincronizzazione devono essere corretti prima di procedere con la dismissione dei sistemi locali.
Sincronizzare Active Directory con Microsoft Entra ID
Se l'obiettivo è integrare il dominio aziendale con Microsoft 365 e le applicazioni cloud, la sincronizzazione delle identità rappresenta spesso il percorso più appropriato. Microsoft Entra Connect Sync oppure Microsoft Entra Cloud Sync possono sincronizzare gli oggetti supportati da Active Directory locale con Microsoft Entra ID, secondo le funzionalità e i requisiti della soluzione scelta.
La sincronizzazione non trasferisce automaticamente nel cloud ogni elemento della directory e non equivale alla migrazione dei domain controller. Utenti, gruppi e attributi vengono gestiti secondo le regole di sincronizzazione, mentre password, autenticazione e dispositivi dipendono dalla configurazione adottata. È quindi necessario definire la sorgente autorevole degli attributi e verificare eventuali duplicati, conflitti tra UPN e indirizzi SMTP e problemi relativi agli attributi utilizzati dalle applicazioni.
La scelta del metodo di autenticazione richiede un'analisi specifica. Password Hash Synchronization consente di sincronizzare una rappresentazione derivata delle password per l'autenticazione cloud, senza copiare la password in chiaro. Pass-through Authentication verifica invece le credenziali attraverso agenti installati nell'ambiente aziendale, mentre la federazione introduce un'infrastruttura di autenticazione separata, da mantenere e proteggere adeguatamente. La scelta deve considerare disponibilità della connettività, requisiti di sicurezza, continuità del servizio e complessità operativa.
Prima di attivare la sincronizzazione in produzione è opportuno verificare il filtraggio degli oggetti, gli attributi obbligatori, le regole di corrispondenza delle identità e i processi di provisioning e deprovisioning. È inoltre importante evitare di creare account cloud duplicati per utenti già presenti in Active Directory, perché conflitti di identità possono complicare l'associazione degli oggetti e compromettere l'accesso alle risorse.
DNS, replica e connettività tra sede aziendale e Azure
Il DNS è uno degli elementi più critici durante la migrazione di Active Directory. I client Windows utilizzano i record DNS specifici del dominio, compresi i record SRV, per individuare i domain controller e i servizi di autenticazione. Se i sistemi ospitati in Azure non riescono a risolvere correttamente tali record, possono verificarsi errori di join al dominio, autenticazione, applicazione delle Group Policy e individuazione dei servizi.
La configurazione deve prevedere una strategia di risoluzione coerente tra le reti locali e le Virtual Network Azure. Le impostazioni devono tenere conto dei DNS interni di Active Directory, dei forwarder e delle modalità con cui le macchine virtuali raggiungono i server DNS. I DNS pubblici non possono sostituire direttamente i DNS interni necessari alla risoluzione dei record del dominio aziendale.
Anche la replica deve essere monitorata con attenzione. Latenza elevata, interruzioni del collegamento VPN e configurazioni errate delle subnet possono influire sulla comunicazione tra domain controller. La progettazione dei siti Active Directory e dei relativi collegamenti consente di controllare la topologia di replica e di adattarla alla distribuzione geografica dei server.
Le regole di rete devono consentire i protocolli richiesti da Active Directory, evitando però di esporre indiscriminatamente i domain controller su Internet. Il traffico amministrativo e di replica deve rimanere su collegamenti privati e segmenti di rete controllati, applicando il principio del privilegio minimo alle regole di accesso.
Migrazione di utenti, computer e Group Policy
Quando il progetto prevede il mantenimento del dominio esistente, la migrazione dei domain controller non richiede necessariamente la ricreazione degli utenti e dei computer: gli oggetti continuano a essere replicati all'interno della stessa directory. Il problema principale consiste nel verificare che dispositivi e applicazioni raggiungano i controller corretti e continuino a ricevere le configurazioni previste.
Le Group Policy devono essere analizzate per individuare dipendenze da percorsi UNC, script di accesso, server di distribuzione software, unità di rete e risorse disponibili soltanto nella sede locale. Se i sistemi vengono trasferiti su una rete Azure, tali dipendenze possono richiedere modifiche ai percorsi, alle regole firewall o alla distribuzione dei servizi.
Nel caso di una migrazione verso una nuova foresta o verso un modello di identità differente, il processo diventa più complesso. Possono essere necessari strumenti specifici per migrare gli oggetti, ricostruire le autorizzazioni e gestire le associazioni tra utenti, gruppi e risorse. Gli identificativi di sicurezza, o SID, e le autorizzazioni NTFS devono essere considerati attentamente per evitare che utenti migrati perdano l'accesso ai file o mantengano privilegi non più necessari.
Per i dispositivi aziendali è inoltre necessario distinguere il join tradizionale ad Active Directory, Microsoft Entra join e Microsoft Entra hybrid join. Questi modelli non sono equivalenti e influenzano la gestione dei dispositivi, l'accesso alle risorse e l'applicazione dei criteri. La scelta deve essere coerente con le applicazioni, gli strumenti di gestione degli endpoint e le politiche di sicurezza dell'organizzazione.
Sicurezza e protezione dell'identità durante la migrazione
La migrazione di Active Directory verso Azure è anche un'occasione per migliorare la sicurezza dell'identità aziendale. I domain controller ospitati nel cloud devono essere trattati come sistemi altamente critici, proteggendo gli accessi amministrativi, limitando le porte esposte e applicando aggiornamenti di sicurezza regolari. L'accesso alle macchine virtuali deve avvenire attraverso canali amministrativi controllati, evitando l'esposizione diretta dei servizi di gestione.
Microsoft Entra ID consente di adottare controlli come l'autenticazione a più fattori, l'accesso condizionale e la valutazione dei rischi di accesso, in base alle licenze e alle funzionalità disponibili. Questi meccanismi possono ridurre il rischio di compromissione degli account, ma devono essere configurati e testati per non bloccare gli accessi amministrativi legittimi.
È importante proteggere anche gli account privilegiati, separando le identità amministrative da quelle utilizzate quotidianamente e limitando i privilegi permanenti. Gli account di emergenza cloud devono essere pianificati e protetti secondo le indicazioni di sicurezza applicabili all'organizzazione. Parallelamente, devono essere verificati i processi di registrazione degli eventi, la conservazione dei log e il monitoraggio delle attività anomale.
La protezione dei dati di directory e delle configurazioni non deve dipendere esclusivamente dalla replica tra domain controller. La replica migliora la disponibilità dei dati, ma può propagare cancellazioni o modifiche errate. Per questo motivo, il piano di migrazione deve includere procedure di backup e ripristino verificate, con particolare attenzione al recupero della directory e delle dipendenze applicative.
Test, cutover e verifica della migrazione
Prima di trasferire definitivamente i servizi, è necessario definire un piano di test che comprenda autenticazione degli utenti, risoluzione DNS, replica, accesso alle risorse condivise, applicazione delle Group Policy e funzionamento delle applicazioni che dipendono dal dominio. La validazione deve essere eseguita con account e dispositivi rappresentativi dei diversi reparti, includendo anche gli scenari di accesso remoto.
Il cutover deve essere pianificato in una finestra controllata, dopo aver verificato la sincronizzazione dei dati, la disponibilità delle risorse e le procedure di rollback. Nel caso di una sostituzione dei domain controller, i ruoli FSMO devono essere trasferiti quando previsto e i vecchi controller devono essere rimossi correttamente dal dominio. La semplice disconnessione o eliminazione di una macchina virtuale non equivale a una dismissione corretta di un domain controller.
Dopo il passaggio è necessario monitorare gli errori di autenticazione, gli eventi di replica, le prestazioni dei servizi e le segnalazioni degli utenti. La documentazione deve essere aggiornata con la nuova topologia, gli indirizzi IP, i server DNS, le dipendenze applicative e le procedure operative. Questa fase permette di individuare problemi residui prima di eliminare definitivamente l'infrastruttura precedente.
Migrare Active Directory su Azure con una strategia strutturata
La migrazione di Active Directory verso Azure richiede competenze che coinvolgono identity management, networking, DNS, sicurezza e gestione dei sistemi Windows. Non esiste un'unica procedura valida per tutte le aziende: mantenere AD DS su macchine virtuali Azure, sincronizzare le identità con Microsoft Entra ID o adottare servizi di dominio gestiti sono scelte architetturali differenti, da valutare sulla base delle applicazioni e dei requisiti operativi.
ALLIT può supportare le aziende nell'analisi dell'infrastruttura Active Directory, nella progettazione della migrazione verso Azure e nella verifica delle dipendenze tra identità, dispositivi e applicazioni. Un approccio tecnico basato su inventario, test, controllo della replica, protezione degli accessi e procedure di ripristino consente di ridurre i rischi del passaggio al cloud e di mantenere affidabili i servizi aziendali durante l'evoluzione dell'infrastruttura.
