Modifica

Distribuire Active Directory Domain Services in una rete virtuale di Azure

Microsoft Entra
Rete virtuale di Azure

Questa architettura illustra come estendere un dominio Active Directory locale ad Azure per fornire servizi di autenticazione distribuiti.

Architettura

Diagram that shows a secure hybrid network architecture with Active Directory.

Scaricare un file di Visio di questa architettura.

Questa architettura estende l'architettura di rete ibrida illustrata in Connessione una rete locale ad Azure usando un gateway VPN.

Workflow

  • Rete locale. La rete locale include i server Active Directory locali che possono gestire l'autenticazione e l'autorizzazione per i componenti situati in locale.
  • Server Active Directory. Questi server sono controller di dominio che implementano servizi directory (AD DS) in esecuzione come macchine virtuali nel cloud. Possono fornire l'autenticazione dei componenti in esecuzione nella rete virtuale di Azure.
  • Subnet di Active Directory. I server Dominio di Active Directory Services (AD DS) sono ospitati in una subnet separata. Le regole del gruppo di sicurezza di rete (NSG) proteggono i server di Active Directory Domain Services e fungono da firewall per il traffico da origini non previste.
  • Sincronizzazione di Azure Gateway VPN e Active Directory. Gateway VPN fornisce una connessione tra la rete locale e Azure Rete virtuale. Questa connessione può essere una connessione VPN o tramite Azure ExpressRoute. Tutte le richieste di sincronizzazione tra i server Active Directory nel cloud e locali passano attraverso il gateway. Le route definite dall'utente gestiscono il routing per il traffico locale che passa in Azure.

Componenti

  • Microsoft Entra ID è un servizio di gestione delle identità aziendale che fornisce l'accesso Single Sign-On, l'autenticazione a più fattori e l'accesso condizionale.
  • Gateway VPN è un servizio che usa un gateway di rete virtuale per inviare traffico crittografato tra una rete virtuale di Azure e le posizioni locali tramite Internet pubblico.
  • ExpressRoute consente di estendere le reti locali nel cloud Microsoft tramite una connessione privata con l'aiuto di un provider di connettività.
  • Rete virtuale è il blocco predefinito fondamentale per le reti private in Azure. È possibile usarlo per abilitare le risorse di Azure, ad esempio le macchine virtuali, per comunicare tra loro, internet e reti locali.

Dettagli dello scenario

Se l'applicazione è ospitata in parte in locale e in parte in Azure, la replica di Active Directory Domain Services in Azure potrebbe risultare più efficiente. Questa replica può ridurre la latenza causata dall'invio di richieste di autenticazione dal cloud ad Active Directory Domain Services in esecuzione in locale.

Per altre considerazioni, vedere Scegliere una soluzione per l'integrazione di Active Directory locale con Azure.

Potenziali casi d'uso

Questa architettura viene comunemente usata quando una connessione VPN o ExpressRoute connette le reti virtuali locali e di Azure. L'architettura supporta anche la replica bidirezionale. Ciò vuol dire che è possibile apportare modifiche sia in locale che nel cloud ed entrambe le origini verranno mantenute coerenti. Gli usi tipici di questa architettura includono applicazioni ibride in cui la funzionalità viene distribuita tra applicazioni e applicazioni locali e applicazioni e servizi che eseguono l'autenticazione con Active Directory.

Consigli

Le raccomandazioni seguenti si applicano alla maggior parte degli scenari. Seguire queste indicazioni, a meno che non si disponga di un requisito specifico che le escluda.

Indicazioni per le VM

Determinare i requisiti di dimensioni delle macchine virtuali in base al volume di richieste di autenticazione previsto. Usare le specifiche dei computer che ospitano Active Directory Domain Services in locale come punto di partenza e associarle alle dimensioni delle macchine virtuali di Azure. Dopo la distribuzione, monitorare l'utilizzo e aumentare o ridurre le prestazioni in base al carico effettivo sulle macchine virtuali. Per altre informazioni sul dimensionamento dei controller di dominio Active Directory Domain Services, vedere Capacity Planning for Active Directory Domain Services (Pianificazione della capacità per Active Directory Domain Services).

Creare un disco dati virtuale separato per archiviare il database, i log e la cartella sysvol per Active Directory. Non archiviare questi elementi nello stesso disco del sistema operativo. Per impostazione predefinita, i dischi dati vengono collegati a una macchina virtuale usando la memorizzazione nella cache write-through. Tuttavia, questa forma di memorizzazione nella cache può essere in conflitto con i requisiti di Active Directory Domain Services. Per questo motivo, impostare l'opzione Preferenze cache dell'host del disco dati su Nessuna.

Distribuire almeno due macchine virtuali che eseguono Active Directory Domain Services come controller di dominio e aggiungerle a zone di disponibilità diverse. Se non è disponibile nell'area, distribuire in un set di disponibilità.

Raccomandazioni di rete

Configurare l'interfaccia di rete della macchina virtuale (NIC) per ogni server di Active Directory Domain Services con un indirizzo IP privato statico per il supporto completo del servizio DNS (Domain Name Service). Per altre informazioni, vedere Come impostare un indirizzo IP statico privato nel portale di Azure.

Nota

Non configurare la scheda di interfaccia di rete della macchina virtuale per servizi di dominio Active Directory con un indirizzo IP pubblico. Vedere le considerazioni relative alla sicurezza per altri dettagli.

Il gruppo di sicurezza di rete della subnet di Active Directory richiede regole per consentire il traffico in ingresso dal traffico locale e in uscita verso l'ambiente locale. Per informazioni dettagliate sulle porte usate da Active Directory Domain Services, vedere Active Directory and Active Directory Domain Services Port Requirements (Requisiti delle porte per Active Directory e Active Directory Domain Services).

Se le nuove macchine virtuali del controller di dominio hanno anche il ruolo dei server DNS, è consigliabile configurarle come server DNS personalizzati a livello di rete virtuale, come illustrato in Modificare i server DNS. Questa operazione deve essere eseguita per la rete virtuale che ospita i nuovi controller di dominio e le reti con peering in cui altre macchine virtuali devono risolvere i nomi di dominio di Active Directory. Per altre informazioni sulla configurazione della risoluzione dei nomi DNS ibrida, vedere Risoluzione dei nomi per le risorse nelle reti virtuali di Azure.

Per la configurazione iniziale, potrebbe essere necessario modificare l'interfaccia di rete di uno dei controller di dominio in Azure, in modo che punti a un controller di dominio locale come origine DNS primaria.

L'inclusione dell'indirizzo IP nell'elenco dei server DNS migliora le prestazioni e aumenta la disponibilità dei server DNS. Tuttavia, un ritardo di avvio può comportare se il server DNS è anche un controller di dominio e punta solo a se stesso o punta a se stesso per la risoluzione dei nomi. Per questo motivo, prestare attenzione quando si configura l'indirizzo di loopback in una scheda se il server è anche un controller di dominio.

Ciò può significare la sovrascrittura delle impostazioni DNS dell'interfaccia di rete in Azure per puntare a un altro controller di dominio ospitato in Azure o in locale per il server DNS primario. L'indirizzo di loopback deve essere configurato solo come server DNS secondario o terziario in un controller di dominio.

Sito Active Directory

In Active Directory Domain Services, un sito rappresenta un percorso fisico, una rete o una raccolta di dispositivi. I siti di Active Directory Domain Services vengono usati per gestire la replica di database di Active Directory Domain Services raggruppando gli oggetti di Active Directory Domain Services vicini tra loro e connessi da una rete ad alta velocità. Active Directory Domain Services include la logica per selezionare la strategia migliore per la replica del database di Active Directory Domain Services tra siti.

È consigliabile creare un sito di Active Directory Domain Services, incluse le subnet definite per l'applicazione in Azure. È quindi possibile configurare un collegamento del sito tra i siti di Active Directory Domain Services locali e Servizi di dominio Active Directory eseguirà automaticamente la replica del database più efficiente possibile. Questa replica di database richiede poco oltre la configurazione iniziale.

Master operazioni di Active Directory

Il ruolo master operazioni può essere assegnato ai controller di dominio di Active Directory Domain Services per supportare il controllo della coerenza tra istanze di database di Active Directory Domain Services replicati. Sono disponibili cinque ruoli master operazioni (FSMO): master dello schema, master dei nomi di dominio, master identificatore relativo, emulatore master controller di dominio primario e master infrastruttura. Per altre informazioni su questi ruoli, vedere Planning operations master role placement.For more information about these roles, see Planning operations master role placement. È consigliabile assegnare almeno due dei nuovi controller di dominio di Azure al ruolo GC (Global Catalog). Altre informazioni sul posizionamento GC sono disponibili qui.

Monitoraggio

Monitorare le risorse delle macchine virtuali del controller di dominio e dei servizi di Active Directory Domain Services e creare un piano per risolvere rapidamente eventuali problemi. Per altre informazioni, vedere Monitoring Active Directory (Monitoraggio di Active Directory). È anche possibile installare strumenti come Microsoft Systems Center nel server di monitoraggio (vedere il diagramma dell'architettura) per agevolare l'esecuzione di queste attività.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni dei clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

Distribuire le macchine virtuali che eseguono Active Directory Domain Services in almeno due zone di disponibilità. Se le zone di disponibilità non sono disponibili nell'area, usare i set di disponibilità. Valutare anche la possibilità di assegnare il ruolo di master operazioni di standby ad almeno un server e possibilmente più, a seconda dei requisiti. Un master operazioni di standby è una copia attiva del master operazioni che può sostituire il server master operazioni primario durante il failover.

Sicurezza

La sicurezza garantisce attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

I server di Active Directory Domain Services offrono servizi di autenticazione e rappresentano un obiettivo ideale per eventuali attacchi. Per proteggerli, impedire la connettività Internet diretta inserendo i server di Active Directory Domain Services in una subnet separata con un gruppo di sicurezza di rete come firewall. Chiudere tutte le porte nei server di Active Directory Domain Services ad eccezione di quelle necessarie per l'autenticazione, l'autorizzazione e la sincronizzazione dei server. Per altre informazioni, vedere Active Directory and Active Directory Domain Services Port Requirements (Requisiti delle porte per Active Directory e Active Directory Domain Services).

Usare BitLocker o Crittografia dischi di Azure per crittografare il disco che ospita il database di Active Directory Domain Services.

Protezione DDoS di Azure, in combinazione con le procedure consigliate per la progettazione di applicazioni, offre funzionalità avanzate di mitigazione DDoS per difendersi meglio dagli attacchi DDoS. È consigliabile abilitare Protezione DDOS di Azure in qualsiasi rete virtuale perimetrale.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono e mantengono un'applicazione in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

  • Usare la procedura IaC (Infrastructure as Code) per effettuare il provisioning e configurare l'infrastruttura di rete e sicurezza. Un'opzione è i modelli di Azure Resource Manager.

  • Isolare i carichi di lavoro per consentire a DevOps di eseguire l'integrazione continua e il recapito continuo (CI/CD) perché ogni carico di lavoro è associato e gestito dal team DevOps corrispondente.

In questa architettura, l'intera rete virtuale che include i diversi livelli applicazione, jump box di gestione e Microsoft Entra Domain Services viene identificato come un singolo carico di lavoro isolato.

Le macchine virtuali vengono configurate usando estensioni macchina virtuale e altri strumenti, ad esempio DSC (Desired State Configuration), usati per configurare Active Directory Domain Services nelle macchine virtuali.

  • Valutare la possibilità di automatizzare le distribuzioni usando Azure DevOps o qualsiasi altra soluzione CI/CD. Azure Pipelines è il componente consigliato di Azure DevOps Services che offre l'automazione per le compilazioni e le distribuzioni di soluzioni ed è altamente integrato nell'ecosistema di Azure.

  • Usare Monitoraggio di Azure per analizzare le prestazioni dell'infrastruttura. Consente anche di monitorare e diagnosticare i problemi di rete senza accedere alle macchine virtuali. Application Insights offre metriche e log avanzati per verificare lo stato dell'infrastruttura.

Per altre informazioni, vedere la sezione DevOps in Microsoft Azure Well-Architected Framework.

Gestione

Eseguire backup regolari di Active Directory Domain Services. Non copiare i file VHD dei controller di dominio anziché eseguire backup regolari perché il file di database di Active Directory Domain Services nel disco rigido virtuale potrebbe non essere coerente quando viene copiato, rendendo impossibile riavviare il database.

Non è consigliabile arrestare una macchina virtuale del controller di dominio usando il portale di Azure. Arrestare e riavviare invece il sistema operativo guest. L'arresto tramite il portale di Azure causa la deallocazione della macchina virtuale, che comporta gli effetti seguenti quando viene riavviata la macchina virtuale del controller di dominio:

  1. Reimposta l'oggetto VM-GenerationID e del invocationID repository di Active Directory
  2. Rimuove il pool di identificatori relativi (RID) di Active Directory corrente
  3. Contrassegna la cartella sysvol come non autenticativa

Il primo problema è relativamente benigno. La reimpostazione ripetuta di causerà un minor utilizzo aggiuntivo della larghezza di invocationID banda durante la replica, ma in genere non è significativo.

Il secondo problema può contribuire all'esaurimento del pool RID nel dominio, soprattutto se le dimensioni del pool RID sono state configurate per essere maggiori del valore predefinito. Si consideri che se il dominio è stato in giro per molto tempo o viene usato per i flussi di lavoro che richiedono la creazione ripetitiva e l'eliminazione degli account, il dominio potrebbe già avvicinarsi all'esaurimento del pool RID. Il monitoraggio del dominio per gli eventi di avviso di esaurimento del pool RID è una procedura consigliata. Vedere l'articolo Gestione del rilascio rid.

Il terzo problema è relativamente dannoso, purché sia disponibile un controller di dominio autorevole quando viene riavviata una macchina virtuale del controller di dominio in Azure. Se tutti i controller di dominio in un dominio sono in esecuzione in Azure e vengono tutti arrestati e deallocati contemporaneamente, in un riavvio, ogni controller di dominio non riuscirà a trovare una replica autorevole. La correzione di questa condizione richiede un intervento manuale: vedere l'articolo Come forzare la sincronizzazione autorevole e non autorevole per la replica sysvol replicata DFSR.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità del carico di lavoro di ridimensionarsi per soddisfare le esigenze poste dagli utenti in modo efficiente. Per altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.

Active Directory Domain Services è progettato per la scalabilità. Non è necessario configurare un servizio di bilanciamento del carico o un controller del traffico per indirizzare le richieste ai controller di dominio Active Directory Domain Services. L'unica considerazione sulla scalabilità consiste nel configurare le macchine virtuali che eseguono Servizi di dominio Active Directory con le dimensioni corrette per i requisiti di carico di rete, monitorare il carico nelle macchine virtuali e aumentare o ridurre le prestazioni in base alle esigenze.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda la riduzione delle spese non necessarie e il miglioramento dell'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Usare il calcolatore dei prezzi di Azure per stimare i costi. Altre considerazioni sono descritte nella sezione Costo in Microsoft Azure Well-Architected Framework.

Ecco alcune considerazioni sui costi per i servizi usati in questa architettura.

AD Domain Services

Prendere in considerazione la possibilità di avere Dominio di Active Directory Servizi come servizio condiviso usato da più carichi di lavoro per ridurre i costi. Per altre informazioni, vedere prezzi di Dominio di Active Directory Services.

Gateway VPN

Il componente principale di questa architettura è il servizio gateway VPN. Vengono addebitati i costi in base all'ora in cui viene effettuato il provisioning e la disponibilità del gateway.

Tutto il traffico in ingresso è gratuito e viene addebitato tutto il traffico in uscita. I costi della larghezza di banda Internet vengono applicati al traffico in uscita della VPN.

Per altre informazioni, vedere Prezzi di Gateway VPN.

Rete virtuale

Rete virtuale è gratuito. Per ogni sottoscrizione è possibile creare fino a 50 reti virtuali in tutte le aree. Tutto il traffico all'interno dei limiti di una rete virtuale è gratuito, quindi la comunicazione tra due macchine virtuali nella stessa rete virtuale è gratuita.

Passaggi successivi