Questa architettura di riferimento illustra come creare un dominio di Active Directory separato in Azure considerato attendibile dai domini nella foresta di Active Directory locale.
Scaricare un file di Visio per l'architettura "Foresta di Active Directory Domain Services".
Active Directory Domain Services archivia le informazioni di identità in una struttura gerarchica. Il nodo principale nella struttura gerarchica è noto come foresta. Una foresta contiene domini e i 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 nei domini locali possono essere considerati attendibili per accedere alle risorse nel dominio di Azure separato.
Gli usi tipici di questa architettura includono mantenere la separazione della sicurezza per le identità e gli oggetti contenuti nel cloud ed eseguire la migrazione di singoli domini da un 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 indicati di seguito.
- Rete locale. La rete locale contiene la propria foresta di Active Directory con i relativi domini.
- Server Active Directory. Sono i controller di dominio che implementano i servizi di dominio in esecuzione come macchine virtuali nel cloud. Questi server ospitano una foresta che contiene uno o più domini, separati da quelli locali.
- Relazione di trust unidirezionale. L'esempio nel diagramma mostra una relazione di 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 viceversa.
- 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 (NSG) proteggono i server di Active Directory Domain Services e fungono da firewall per il traffico da origini non previste.
- Gateway di Azure. Il gateway di Azure fornisce una connessione tra la rete virtuale di Azure e la rete locale. 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 Estensione di Active Directory Domain Services (AD DS) ad Azure.
Attendibilità
I domini locali sono contenuti in una foresta diversa rispetto ai 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 offre un dominio di accesso per gli utenti esterni, può essere necessario che la foresta locale consideri attendibile il dominio cloud.
È possibile stabilire trust a livello di foresta creando trust tra foreste o a livello di dominio creando 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 i due domini specificati. È consigliabile creare trust a livello di dominio esterno solo tra domini in foreste diverse.
I trust con un Active Directory locale sono solo unidirezionali (unidirezionali). Un trust unidirezionale consente agli utenti in un dominio o foresta (noti come dominio o foresta in ingresso) per accedere alle risorse contenute in un altro dominio o foresta (il dominio o foresta in uscita).
La tabella seguente presenta un riepilogo delle configurazioni di trust per alcuni semplici scenari:
| Scenario | Trust locale | Trust 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 nel cloud, ma non viceversa | Unidirezionale in uscita | Unidirezionale in ingresso |
Considerazioni sulla scalabilità
Active Directory offre scalabilità automatica per i controller di dominio che fanno parte dello stesso dominio. Le richieste vengono distribuite tra tutti i controller all'interno di un dominio. È possibile aggiungere un altro controller di dominio, che viene sincronizzato automaticamente con il dominio. Non configurare un dispositivo di bilanciamento del carico separato per indirizzare il traffico verso i controller all'interno del dominio. Verificare che tutti i controller di dominio dispongano di risorse di memoria e archiviazione sufficienti per gestire il database del dominio. Impostare dimensioni uguali per tutte le macchine virtuali del controller di dominio.
Considerazioni sulla disponibilità
Eseguire il provisioning di almeno due controller di dominio per ogni dominio. Questo consente la replica automatica tra server. Creare un set di disponibilità per le macchine virtuali che fungono da server Active Directory per la gestione di ogni dominio. In questo set di disponibilità, inserire almeno due server.
Inoltre, è opportuno designare uno o più server in ogni dominio come master operazioni in standby, in caso di errori di connettività con un server che riveste il ruolo FSMO (Flexible Single Master Operation).
Considerazioni sulla gestibilità
Per considerazioni sulla gestione e il monitoraggio, vedere Estensione di Active Directory Domain Services in Azure.
Per altre informazioni, vedere Monitoring Active Directory (Monitoraggio di Active Directory). È possibile installare strumenti come Microsoft Systems Center in un server di monitoraggio della subnet di gestione per agevolare l'esecuzione di queste attività.
Considerazioni relative alla sicurezza
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, la relazione di trust viene estesa ai nuovi domini creati in entrambe le foreste. Se si usano i domini per implementare la separazione a scopo di sicurezza, è consigliabile creare trust solo a livello di dominio. I trust a livello di dominio sono non transitivi.
Per considerazioni sulla sicurezza specifiche di Active Directory, vedere la sezione corrispondente in Estensione di Active Directory Domain Services in Azure.
Considerazioni su DevOps
Per considerazioni su DevOps, vedere Eccellenza operativa nell'estensione di Active Directory Domain Services (AD DS) ad Azure.
Considerazioni sul costo
Usare il calcolatore dei prezzi di Azure per stimare i costi. Altre considerazioni sono descritte nella sezione Costi in Microsoft Azure Well-Architected Framework.
Ecco alcune considerazioni sui costi per i servizi usati in questa architettura.
AD Domain Services
Valutare se scegliere Active Directory Domain Services come servizio condiviso utilizzato da più carichi di lavoro per ridurre i costi. Per altre informazioni, vedere prezzi di Active Directory Domain Services.
Gateway VPN di Azure
Il componente principale di questa architettura è il servizio gateway VPN. L'importo addebitato è basato sulla quantità di tempo durante il quale il gateway viene sottoposto a provisioning e risulta disponibile.
Tutto il traffico in ingresso è gratuito, 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.
Passaggi successivi
- Procedure consigliate per estendere il dominio di Active Directory Domain Services in Azure
- Procedure consigliate per creare un'infrastruttura Active Directory Federation Services in Azure.