Questa architettura di riferimento illustra come creare un dominio Active Directory separato in Azure considerato attendibile dai domini nella foresta AD locale.
Scaricare un file di Visio per l'architettura della foresta di Active Directory Domain Services.
Active Directory Domain Services (AD DS) archivia le informazioni sull'identità in una struttura gerarchica. Il nodo superiore nella struttura gerarchica è noto come foresta. Una foresta contiene domini e domini contengono altri tipi di oggetti. Questa architettura di riferimento crea una foresta di Active Directory Domain Services in Azure con una relazione di trust unidirezionale in uscita con un dominio locale. La foresta in Azure contiene un dominio che non esiste in locale. A causa della relazione di trust, gli accessi effettuati sui domini locali possono essere considerati attendibili per l'accesso alle risorse nel dominio di Azure separato.
Gli usi tipici di questa architettura includono la gestione della separazione della sicurezza per oggetti e identità contenuti nel cloud e la migrazione di singoli domini dall'ambiente locale al cloud.
Per altre considerazioni, vedere Scegliere una soluzione per l'integrazione di Active Directory locale con Azure.
Architettura
L'architettura include i componenti seguenti.
- rete locale. La rete locale contiene la propria foresta e domini di Active Directory.
- server Active Directory. Si tratta di controller di dominio che implementano i servizi di dominio in esecuzione come macchine virtuali nel cloud. Questi server ospitano una foresta contenente uno o più domini, separati da quelli situati in locale.
- relazione di trust unidirezionale. L'esempio nel diagramma mostra un trust unidirezionale dal dominio in Azure al dominio locale. Questa relazione consente agli utenti locali di accedere alle risorse nel dominio in Azure, ma non in altro modo.
- subnet di Active Directory. I server di Active Directory Domain Services sono ospitati in una subnet separata. Le regole del gruppo di sicurezza di rete proteggono i server di Active Directory Domain Services e forniscono un firewall dal traffico da origini impreviste.
- gateway di Azure. Il gateway di Azure fornisce una connessione tra la rete locale e la rete virtuale di Azure. Può trattarsi di una connessione VPN o Azure ExpressRoute. Per altre informazioni, vedere Connettere una rete locale ad Azure usando un gateway VPN.
Consigli
Per consigli specifici sull'implementazione di Active Directory in Azure, vedere l'estensione di Active Directory Domain Services (AD DS) ad Azure.
Fiducia
I domini locali sono contenuti all'interno di una foresta diversa dai domini nel cloud. Per abilitare l'autenticazione degli utenti locali nel cloud, i domini in Azure devono considerare attendibile il dominio di accesso nella foresta locale. Analogamente, se il cloud fornisce un dominio di accesso per gli utenti esterni, potrebbe essere necessario che la foresta locale consideri attendibile il dominio cloud.
È possibile stabilire trust a livello di foresta la creazione di trust tra foresteo a livello di dominio la creazione di trust esterni. Un trust a livello di foresta crea una relazione tra tutti i domini in due foreste. Un trust a livello di dominio esterno crea solo una relazione tra due domini specificati. È consigliabile creare trust a livello di dominio esterno solo tra domini in foreste diverse.
I trust con un'istanza di Active Directory locale sono solo unidirezionali (unidirezionali). Un trust unidirezionale consente agli utenti di un dominio o di una foresta (noto come dominio o foresta in ingresso) di accedere alle risorse contenute in un altro (il dominio o foresta in uscita).
La tabella seguente riepiloga le configurazioni di attendibilità per alcuni scenari semplici:
Scenario | Attendibilità locale | Attendibilità cloud |
---|---|---|
Gli utenti locali richiedono l'accesso alle risorse nel cloud, ma non viceversa | Unidirezionale, in ingresso | Unidirezionale, in uscita |
Gli utenti nel cloud richiedono l'accesso alle risorse che si trovano in locale, ma non viceversa | Unidirezionale, in uscita | Unidirezionale, in ingresso |
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, ovvero un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.
Effettuare il provisioning di almeno due controller di dominio per ogni dominio. In questo modo è possibile eseguire la replica automatica tra server. Creare un set di disponibilità per le macchine virtuali che fungono da server Active Directory che gestiscono ogni dominio. Inserire almeno due server in questo set di disponibilità.
Inoltre, valutare la possibilità di designare uno o più server in ogni dominio come master operazioni di standby nel caso in cui la connettività a un server che agisca come un ruolo FSMO (Single Master Operation) flessibile ha esito negativo.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Security.
I trust a livello di foresta sono transitivi. Se si stabilisce un trust a livello di foresta tra una foresta locale e una foresta nel cloud, questo trust viene esteso ad altri nuovi domini creati in entrambe le foreste. Se si usano domini per garantire la separazione a scopo di sicurezza, è consigliabile creare trust solo a livello di dominio. I trust a livello di dominio non sono transitivi.
Per considerazioni sulla sicurezza specifiche di Active Directory, vedere la sezione Considerazioni sulla sicurezza in l'estensione di Active Directory ad Azure.
Ottimizzazione costi
L'ottimizzazione dei costi consiste nell'esaminare i modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.
Usare calcolatore 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.
Servizi di dominio Active Directory
Prendere in considerazione l'uso di Servizi di dominio Active Directory come servizio condiviso utilizzato da più carichi di lavoro per ridurre i costi. Per altre informazioni, vedere prezzi di Servizi di dominio Active Directory.
Azure VPN Gateway
Il componente principale di questa architettura è il servizio gateway VPN. Vengono addebitati i costi in base alla quantità di tempo di provisioning e disponibilità del gateway.
Tutto il traffico in ingresso è gratuito, viene addebitato tutto il traffico in uscita. I costi della larghezza di banda Internet vengono applicati al traffico vpn in uscita.
Per altre informazioni, vedere prezzi gateway VPN.
Eccellenza operativa
L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.
DevOps
Per considerazioni su DevOps, vedere Operational Excellence in Extending Active Directory Domain Services (AD DS) to Azure.
Maneggiabilità
Per informazioni sulle considerazioni sulla gestione e il monitoraggio, vedere l'estensione di Active Directory ad Azure.
Seguire le indicazioni riportate in Monitoraggio di Active Directory. È possibile installare strumenti come Microsoft Systems Center in un server di monitoraggio nella subnet di gestione per eseguire queste attività.
Efficienza delle prestazioni
L'efficienza delle prestazioni è la capacità del carico di lavoro di soddisfare le esigenze poste dagli utenti in modo efficiente. Per altre informazioni, vedere Elenco di controllo per l'efficienza delle prestazioni.
Active Directory è scalabile automaticamente per i controller di dominio che fanno parte dello stesso dominio. Le richieste vengono distribuite in tutti i controller all'interno di un dominio. È possibile aggiungere un altro controller di dominio e sincronizzarlo automaticamente con il dominio. Non configurare un servizio di bilanciamento del carico separato per indirizzare il traffico ai controller all'interno del dominio. Assicurarsi che tutti i controller di dominio dispongano di risorse di memoria e archiviazione sufficienti per gestire il database di dominio. Rendere tutte le macchine virtuali del controller di dominio le stesse dimensioni.
Passaggi successivi
- Informazioni sulle procedure consigliate per l'estensione del dominio di Active Directory Domain Services locale ad Azure
- Informazioni sulle procedure consigliate per la creazione di un'infrastruttura AD FS in Azure.