Posso usare RDP sui controller di dominio quando utilizzo Entra Domain Services?

No. Microsoft gestisce completamente l'infrastruttura sottostante dei controller di dominio, il che significa che non hai accesso amministrativo al sistema operativo né la possibilità di connetterti ai controller di dominio tramite Desktop remoto.

In che modo le identità vengono sincronizzate con Entra Domain Services?

Le identità fluiscono in un'unica direzione, dalla fonte autorevole (Entra ID per gli utenti cloud, oppure Active Directory locale tramite Microsoft Entra Connect) verso il dominio gestito. Le modifiche apportate direttamente nel dominio gestito non vengono sincronizzate a ritroso.

Migrazione di app legacy su Azure: quando scegliere Microsoft Entra Domain Services rispetto ai controller di dominio IaaS

Q: Cosa succede alle password degli utenti quando si abilita Entra Domain Services?

Perché l'autenticazione Kerberos e NTLM funzioni, Entra Domain Services richiede dati di hash specifici. Per gli utenti solo cloud, questo di solito significa che gli utenti devono modificare la password dopo l'abilitazione del dominio gestito, in modo da generare gli hash crittografici necessari.

Q: Posso modificare lo schema di Active Directory in Entra Domain Services?

No. Trattandosi di un servizio cloud completamente gestito, gli amministratori non possono modificare lo schema sottostante di Active Directory né eseguire operazioni di scrittura LDAP che alterano le strutture principali della directory.

By Mirko Peters · 2026-08-14

Confronta Microsoft Entra Domain Services e i controller di dominio IaaS in Azure. Scopri i compromessi architetturali per la migrazione di app legacy.

Automatically translated with AI from the original post. Read the English original

Cover: Microsoft Entra Domain Services - Simply Explained

Quando si esegue il lift and shift di applicazioni Windows legacy su Azure, gli architetti si trovano di fronte a un dilemma critico sull'identità: conviene distribuire macchine virtuali con controller di dominio Active Directory tradizionali oppure usare servizi cloud gestiti? Questa guida esamina i compromessi architetturali, il carico operativo e le implicazioni sui costi della scelta di Microsoft Entra Domain Services rispetto a controller di dominio IaaS personalizzati per i carichi di lavoro legacy su Azure.

Punti chiave

Microsoft Entra Domain Services offre le funzionalità tradizionali dei domini Windows in modalità gestita, senza che il team IT debba distribuire, applicare patch o ripristinare le macchine virtuali dei controller di dominio.
Distribuire controller di dominio IaaS in Azure dà agli amministratori il controllo completo, inclusi l'accesso RDP e i privilegi di Domain Admin, ma aumenta in modo significativo il carico operativo.
I carichi di lavoro legacy che dipendono da LDAP, Kerberos, NTLM o Criteri di gruppo possono essere eseguiti in Azure senza interruzioni, utilizzando un livello di compatibilità del dominio gestito.
Entra Domain Services applica un modello di sincronizzazione delle identità rigorosamente unidirezionale, per cui i record utente devono essere gestiti nella fonte autorevole e non direttamente nel dominio gestito.
La scelta dell'architettura di identità più adatta dipende in larga misura dai requisiti dell'applicazione, come l'accesso di scrittura LDAP e le modifiche allo schema.

Il dilemma della migrazione legacy su Azure

Spostare un'applicazione aziendale legacy da una sala server locale a una macchina virtuale Azure non rende automaticamente nativa per il cloud quell'applicazione. Molte applicazioni Windows consolidate, come i sistemi ERP legacy, le piattaforme finanziarie e le applicazioni .NET personalizzate, sono state progettate attorno a Active Directory tradizionale. Quando questi carichi di lavoro arrivano nel cloud, si aspettano ancora di interrogare i servizi di directory tramite LDAP, di autenticarsi con ticket Kerberos o di applicare impostazioni tramite Criteri di gruppo.

Gli architetti cloud devono subito prendere una decisione strategica. Puoi collegare la tua rete virtuale Azure ai controller di dominio locali tramite un tunnel VPN ibrido, ma questo introduce latenza e crea un pericoloso punto di guasto singolo se il collegamento di rete si interrompe. In alternativa, puoi creare nuove macchine virtuali Windows Server in Azure, promuoverle a controller di dominio e costruire una foresta o un dominio di replica completamente nuovi.

Creare le proprie macchine virtuali con controller di dominio in Azure offre un controllo totale, ma trasforma anche il team dell'infrastruttura cloud in amministratori di Active Directory a tutti gli effetti. Diventi interamente responsabile della applicazione di patch al sistema operativo, del monitoraggio della replica della directory, della pianificazione del disaster recovery e della protezione degli account con privilegi elevati dal furto di credenziali. Per le organizzazioni che vogliono ridurre il carico operativo mantenendo in esecuzione le applicazioni legacy, questo è spesso un onere non necessario.

Entra Domain Services e controller di dominio IaaS: principali differenze architetturali

Comprendere la differenza architetturale tra l'uso di Microsoft Entra Domain Services e la creazione di controller di dominio IaaS personalizzati è essenziale per progettare ambienti cloud Azure resilienti. Entra Domain Services funziona come un livello di compatibilità gestito. Microsoft gestisce e mantiene in background l'infrastruttura sottostante dei controller di dominio, garantendo alta disponibilità, backup automatici e sincronizzazione in background con Entra ID.

Quando usi Entra Domain Services, le tue macchine virtuali Azure possono aggiungersi al dominio, eseguire query LDAP e gestire gli accessi Kerberos o NTLM senza che i tuoi sistemisti debbano mai collegarsi in desktop remoto a un controller di dominio. Tuttavia, questo compromesso tipico dei servizi gestiti comporta la rinuncia al controllo amministrativo diretto. Non puoi accedere al sistema operativo sottostante, non puoi modificare lo schema di Active Directory e non ricevi i privilegi di Domain Admin o Enterprise Admin.

Al contrario, distribuire controller di dominio IaaS ti dà il pieno controllo sull'architettura della directory. Puoi estendere lo schema, configurare relazioni di trust personalizzate, aggiungere unità organizzative arbitrarie e implementare oggetti criteri di gruppo specializzati senza restrizioni. Il prezzo di questa flessibilità è la manutenzione. Il tuo team deve gestire l'intero ciclo di vita del dominio, inclusi controlli proattivi dello stato di salute, deframmentazione del database e procedure di ripristino d'emergenza in caso di arresto anomalo di un controller di dominio.

Compromessi operativi e salvaguardie amministrative

Prima di scegliere un approccio di dominio gestito in Azure, gli amministratori cloud devono valutare con attenzione come cambiano le operazioni quotidiane. Con i controller di dominio IaaS personalizzati, il tuo team ha un controllo granulare su ogni aspetto della directory. Puoi scrivere script PowerShell personalizzati per automatizzare le attività amministrative, installare direttamente sui controller di dominio agenti di sicurezza di terze parti e risolvere gli errori di replica usando utility native come repadmin.

Microsoft Entra Domain Services sostituisce questo approccio pratico con salvaguardie gestite. L'amministrazione viene eseguita tramite un gruppo dedicato chiamato Entra Domain Services Administrators, utilizzando utility di gestione installate su una macchina virtuale Windows separata e aggiunta al dominio. Sebbene tu possa creare unità organizzative personalizzate, gestire i record DNS e applicare le impostazioni supportate dei criteri di gruppo, sei rigorosamente escluso dall'infrastruttura centrale.

Inoltre, la gestione delle identità segue un modello di sincronizzazione rigorosamente unidirezionale. Le identità di utenti e gruppi passano dalla fonte autorevole, ovvero utenti solo cloud in Entra ID oppure identità sincronizzate da un Active Directory locale, al dominio gestito. Non devi mai tentare di usare Entra Domain Services come directory primaria per modificare gli attributi utente, perché tali modifiche non verranno sincronizzate a monte e verranno prima o poi sovrascritte.

Schema decisionale: come fare la scelta architetturale giusta

Scegliere l'approccio corretto richiede di valutare i requisiti tecnici specifici della tua organizzazione e la strategia cloud a lungo termine. Se il tuo obiettivo principale è migrare i carichi di lavoro legacy in Azure eliminando il costo operativo di gestire macchine virtuali Windows Server come controller di dominio, un servizio gestito è quasi sempre la strada preferita.

Usa Microsoft Entra Domain Services quando:

Stai migrando applicazioni legacy in Azure che richiedono letture LDAP, Kerberos, NTLM o funzionalità di aggiunta al dominio.
La tua organizzazione vuole evitare l'onere di applicare patch, monitorare e ripristinare macchine virtuali dedicate a controller di dominio in Azure.
Operi con un'organizzazione cloud-first o solo cloud e ti servono servizi di dominio tradizionali per un piccolo sottoinsieme di carichi di lavoro Azure, senza costruire una presenza locale.
Le applicazioni richiedono l'applicazione standard dei criteri di gruppo o la gestione degli account di servizio all'interno di una rete virtuale sicura.

Scegli controller di dominio IaaS personalizzati quando:

Le tue applicazioni legacy richiedono accesso in scrittura LDAP o modifiche allo schema di Active Directory.
La tua architettura aziendale richiede foreste multi-dominio complesse, configurazioni di trust personalizzate o accesso diretto ai sistemi operativi dei controller di dominio.
Il tuo team di sicurezza richiede il pieno controllo amministrativo, inclusi i privilegi di Enterprise Admin e la distribuzione diretta di strumenti specializzati per l'audit della directory.

Conclusioni e prossimi passi

Progettare un'architettura di identità solida in Azure richiede di abbinare ogni carico di lavoro al modello di autenticazione esatto di cui ha bisogno. Mentre le moderne applicazioni cloud sfruttano Microsoft Entra ID per il single sign-on basato su token sicuro e per l'autenticazione a più fattori, i carichi di lavoro legacy spesso richiedono i tradizionali servizi di dominio Windows. Decidere se distribuire servizi cloud gestiti o costruire una propria infrastruttura IaaS determina il carico operativo continuo del tuo team.

Per approfondire l'argomento e ascoltare le opinioni di esperti su sicurezza dell'ambiente di lavoro moderno, architettura cloud e strategie di Microsoft 365, ascolta la discussione completa nel podcast. Ascolta l'episodio completo per approfondire la gestione delle identità Microsoft.

Domande frequenti

Posso connettermi tramite RDP ai controller di dominio quando utilizzo Entra Domain Services?

No. Microsoft gestisce interamente l'infrastruttura sottostante dei controller di dominio, il che significa che non disponi di accesso amministrativo al sistema operativo né della possibilità di connetterti in desktop remoto ai controller di dominio.

Cosa succede alle password degli utenti quando si abilita Entra Domain Services?

Affinché l'autenticazione Kerberos e NTLM funzioni, Entra Domain Services richiede dati hash specifici. Per gli utenti solo cloud, questo di solito significa che gli utenti devono modificare la password dopo l'abilitazione del dominio gestito, in modo da generare gli hash crittografici necessari.

Posso modificare lo schema di Active Directory in Entra Domain Services?

No. Poiché si tratta di un servizio cloud completamente gestito, gli amministratori non possono modificare lo schema sottostante di Active Directory né eseguire operazioni di scrittura LDAP che alterano le strutture principali della directory.

Come avviene la sincronizzazione delle identità con Entra Domain Services?

Le identità fluiscono in modo unidirezionale dalla fonte autorevole (Entra ID per gli utenti cloud, oppure Active Directory locale tramite Entra Connect) verso il dominio gestito. Le modifiche apportate direttamente nel dominio gestito non vengono sincronizzate a ritroso verso la fonte.