Esporta (0) Stampa
Espandi tutto

Linee guida per la distribuzione di Active Directory di Windows Server in macchine virtuali di Azure

Aggiornamento: novembre 2014

In questo documento vengono illustrate le differenze principali tra la distribuzione in locale e la distribuzione in macchine virtuali di Microsoft Azure di Servizi di dominio Active Directory e Active Directory Federation Services (ADFS) di Windows Server.

Sommario

Questo documento è destinato a utenti già esperti nella distribuzione di Active Directory in locale. Nel documento sono illustrate le differenze tra la distribuzione di Active Directory in macchine virtuali/reti virtuali di Microsoft Azure e le distribuzioni tradizionali di Active Directory in locale. Macchine virtuali di Azure e Rete virtuale di Azure fanno parte di una soluzione IaaS (Infrastructure-as-a-Service, Infrastruttura come servizio) che offre alle organizzazioni la possibilità di usare risorse di elaborazione nel cloud.

Per gli utenti che non hanno familiarità con la distribuzione di Active Directory, vedere la pagina relativa alla guida alla distribuzione di Servizi di dominio Active Directory o Pianificazione della distribuzione di ADFS in base alle esigenze.

Nel documento si presuppone che il lettore abbia familiarità con i concetti seguenti:

  • Distribuzione e gestione di Servizi di dominio Active Directory di Windows Server

  • Distribuzione e configurazione di DNS per supportare un'infrastruttura di Servizi di dominio Active Directory di Windows Server

  • Distribuzione e gestione di ADFS di Windows Server

  • Distribuzione, configurazione e gestione di applicazioni relying party (siti Web e servizi Web) che possono usare token di ADFS di Windows Server

  • Concetti generali relativi alla macchina virtuale, ad esempio come configurare una macchina virtuale, i dischi virtuali e le reti virtuali

Nel documento vengono illustrati i requisiti per uno scenario di distribuzione ibrida in cui ADFS o Servizi di dominio Active Directory di Windows Server vengono distribuiti in parte in locale e in parte in macchine virtuali di Azure. Nella prima parte del documento vengono descritte le differenze principali tra l'esecuzione in macchine virtuali di Azure e l'esecuzione in locale di Servizi di dominio Active Directory e ADFS di Windows Server. Inoltre, vengono illustrate importanti decisioni che interessano la progettazione e la distribuzione. Nella restante parte del documento vengono spiegate in modo più dettagliato le linee guida relative a ciascuna decisione e la modalità di applicazione di queste indicazioni nei vari scenari di distribuzione.

Il documento non descrive la configurazione di Active Directory di Azure, un servizio basato su REST che fornisce funzionalità di gestione delle identità e controllo di accesso per applicazioni cloud. Azure Active Directory e Servizi di dominio Active Directory di Windows Server sono, tuttavia, progettati per interagire in modo da garantire una soluzione di gestione dell'identità e dell'accesso per le applicazioni moderne e per gli ambienti IT ibridi attuali. Per comprendere le differenze e le relazioni tra Servizi di dominio Active Directory di Windows Server e Active Directory di Azure, si tenga presente quanto riportato di seguito:

  1. È possibile eseguire Servizi di dominio Active Directory di Windows Server nel cloud in macchine virtuali di Azure quando si usa Azure per estendere il data center locale nel cloud.

  2. È possibile usare Azure AD per fornire agli utenti l'accesso Single Sign-On ad applicazioni SaaS (Software as a Service, Software come servizio). Questa tecnologia viene usata, ad esempio, in Microsoft Office 365, nonché in applicazioni in esecuzione in Azure o in altre piattaforme cloud.

  3. È possibile usare il servizio di controllo di accesso di Azure AD per consentire agli utenti l'accesso mediante identità di Facebook, Google, Microsoft e di altri provider di identità ad applicazioni ospitate nel cloud o in locale.

Per altre informazioni su queste differenze, vedere la pagina relativa all'identità di Azure.

È possibile scaricare ed eseguire lo strumento per la preparazione a Macchine virtuali di Azure. Lo strumento di valutazione esamina l'ambiente locale e genera un report personalizzato in base alle linee guida fornite in questo argomento per supportare la migrazione dell'ambiente ad Azure.

È consigliabile esaminare innanzitutto le esercitazioni, le guide e i video relativi agli argomenti seguenti:

Esistono differenze minime tra i requisiti essenziali per la distribuzione in macchine virtuali di Azure e la distribuzione in macchine virtuali (e, in una certa misura, macchine fisiche) in locale di Active Directory di Windows Server. Ad esempio, nel caso di Servizi di dominio Active Directory di Windows Server, se i controller di dominio distribuiti nelle macchine virtuali di Azure sono repliche in un dominio/foresta aziendale locale esistente, la distribuzione di Azure viene gestita, in gran parte, con la stessa modalità con cui si può gestire qualsiasi altro sito Active Directory di Windows Server aggiuntivo. In altre parole, le subnet devono essere definite in Servizi di dominio Active Directory di Windows Server, deve essere creato un sito, le subnet devono essere collegate a questo sito e connesse ad altri siti usando collegamenti di sito appropriati. Vi sono, tuttavia, alcune differenze che sono comuni a tutte le distribuzioni di Azure e altre che variano invece in base allo scenario specifico di distribuzione. Di seguito sono descritte due differenze fondamentali, che vengono illustrate in modo più dettagliato nei paragrafi seguenti:

  1. Potrebbe essere necessario fare in modo che le macchine virtuali di Azure vengano connesse alla rete aziendale locale

    Per la riconnessione di macchine virtuali di Azure a una rete aziendale locale è necessario Rete virtuale di Azure, in cui è incluso un componente VPN (rete privata virtuale) da sito a sito o da sito a punto tramite cui è possibile connettere, senza problemi, le macchine virtuali di Azure e le macchine locali. Grazie a questo componente VPN è inoltre possibile consentire ai computer membri del dominio locale di accedere a un dominio Active Directory di Windows Server i cui controller di dominio sono ospitati esclusivamente in macchine virtuali di Azure. È tuttavia importante notare che, se l'operazione del componente VPN non viene completata correttamente, anche l'autenticazione e le altre operazioni che dipendono da Active Directory di Windows Server avranno esito negativo. Sebbene gli utenti possano accedere usando le credenziali esistenti memorizzate nella cache, tutti i tentativi di autenticazione peer-to-peer o da client a server per cui i ticket devono ancora essere emessi o risultano non aggiornati avranno esito negativo.

    Per un video dimostrativo e un elenco di esercitazioni dettagliate, tra cui Configurare una VPN da sito a sito nel portale di gestione, vedere la pagina relativa alla rete virtuale.

    noteNota
    È inoltre possibile distribuire Active Directory di Windows Server in una rete virtuale di Azure non connessa a una rete locale. Nelle linee guida illustrate in questo argomento, tuttavia, si presuppone l'utilizzo di una rete virtuale di Azure, dal momento che essa fornisce funzionalità di impostazione degli indirizzi IP essenziali per Windows Server.

  2. Devono essere configurati indirizzi IP statici tramite Azure PowerShell.

    Gli indirizzi dinamici vengono allocati per impostazione predefinita, ma usare il cmdlet Set-AzureStaticVNetIP per assegnare invece un indirizzo IP statico. In questo modo viene impostato un indirizzo IP statico che verrà mantenuto durante la correzione dei servizi e l'arresto o il riavvio della macchina virtuale. Per altre informazioni, vedere la pagina relativa alla configurazione di un indirizzo IP interno statico per una macchina virtuale.

Nell'elenco non completo di termini riportato di seguito vengono definite varie tecnologie di Azure pertinenti. Inoltre, viene fornito il supporto necessario per la comprensione del presente documento.

  • Macchine virtuali di Azure: soluzione IaaS di Azure che consente ai clienti di distribuire VM in cui vengono eseguiti quasi tutti i carichi di lavoro del server locale tradizionali.

  • Rete virtuale di Azure: servizio di rete in Azure che consente ai clienti di creare e gestire reti virtuali in Azure e di collegare queste reti in modo sicuro alla propria infrastruttura di rete locale tramite una rete privata virtuale (VPN).

  • Indirizzo IP virtuale (VIP): indirizzo IP con connessione Internet non associato a una scheda di interfaccia di rete o a un computer specifico. Ai servizi cloud viene assegnato un indirizzo IP virtuale per ricevere il traffico di rete che viene reindirizzato a una macchina virtuale di Azure. Un indirizzo IP virtuale è una proprietà di un servizio cloud in cui possono essere contenute una o più macchine virtuali di Azure. Si noti inoltre che in una rete virtuale di Azure possono essere inclusi uno o più servizi cloud. I VIP garantiscono funzionalità native di bilanciamento del carico.

  • Indirizzo IP dinamico (DIP): Questo indirizzo IP è solo interno. Deve essere configurato come indirizzo IP statico (con il cmdlet Set-AzureStaticVNetIP) per le macchine virtuali che ospitano i ruoli del server controller di dominio/DNS.

  • Correzione del servizio: processo durante il quale tramite Azure un servizio viene riportato automaticamente a uno stato di esecuzione in seguito al rilevamento della condizione di errore del servizio. La correzione del servizio è uno degli aspetti di Azure che supporta la disponibilità e la resilienza. Sebbene poco probabile, la conseguenza di un intervento di correzione del servizio per un controller di dominio in esecuzione in una VM è analoga a un riavvio non pianificato, ma con pochi effetti collaterali:

    • L'adattatore di rete virtuale nella VM verrà modificato

    • L'indirizzo MAC dell'adattatore di rete virtuale verrà modificato

    • L'ID CPU/processore della VM verrà modificato

    • La configurazione IP della scheda di rete virtuale non cambierà purché la macchina virtuale sia collegata a una rete virtuale e l'indirizzo IP della macchina virtuale sia statico.

    Nessuno di questi comportamenti influisce su Active Directory di Windows Server, poiché non dipende dall'indirizzo MAC o dall'ID CPU/processore. Inoltre, come illustrato in precedenza, è consigliabile eseguire tutte le distribuzioni di Active Directory di Windows Server in una rete virtuale di Azure.

La distribuzione di controller di dominio Active Directory di Windows Server in macchine virtuali di Azure è soggetta alle stesse linee guida dell'esecuzione di controller di dominio in locale in una macchina virtuale. L'esecuzione di controller di dominio virtualizzati è un'operazione sicura finché si seguono le linee guida per il backup e ripristino dei controller di dominio. Per altre informazioni sui vincoli e sulle linee guida per l'esecuzione di controller di dominio virtualizzati, vedere Esecuzione di controller di dominio in Hyper-V.

Tramite gli hypervisor vengono fornite o banalizzate tecnologie che possono causare problemi a numerosi sistemi distribuiti, tra cui Active Directory di Windows Server. Ad esempio, in un server fisico è possibile clonare un disco o usare metodi non supportati per il rollback dello stato di un server, incluso l'utilizzo di reti SAN e così via, ma l'esecuzione di queste operazioni in un server fisico risulta molto più difficile del ripristino dello snapshot di una macchina virtuale in un hypervisor. Azure offre funzionalità che possono generare la stessa condizione indesiderata. Non è ad esempio consigliabile copiare file VHD di controller di dominio anziché eseguire backup regolari, perché il ripristino di questi file può generare una situazione analoga all'uso delle funzionalità di ripristino di snapshot.

Tramite questi rollback vengono introdotte bolle USN che possono determinare uno stato divergente definitivo tra i controller di dominio. Inoltre, possono essere generate altre conseguenze, tra cui:

  • Oggetti residui

  • Password incoerenti

  • Valori di attributi incoerenti

  • Mancata corrispondenza dello schema in caso di rollback del master schema

Per altre informazioni sull'impatto sui controller di dominio, vedere la pagina relativa a USN e rollback di USN.

A partire da Windows Server 2012, sono state incorporate misure di sicurezza aggiuntive in Servizi di dominio Active Directory. Queste misure di sicurezza permettono di proteggere i controller di dominio virtualizzati dai problemi descritti precedentemente, purché la piattaforma hypervisor sottostante supporti VM-GenerationID. Azure supporta VM-GenerationID, ciò significa che i controller di dominio che eseguono Windows Server 2012 o versioni successive nelle macchine virtuali di Azure dispongono di misure di sicurezza aggiuntive.

noteNota
È consigliabile arrestare e riavviare una macchina virtuale che esegue il ruolo controller di dominio in Azure nel sistema operativo guest, anziché usare l'opzione Arresta nel portale di gestione di Azure. Oggi, l'uso del portale di gestione per arrestare una macchina virtuale comporta la deallocazione della macchina virtuale. Una macchina virtuale deallocata ha il vantaggio di non essere soggetta ad addebiti, ma reimposta anche l'attributo VM-GenerationID, approccio sconsigliato per un controller di dominio. Quando l'attributo VM-GenerationID viene reimpostato, viene reimpostato anche l'attributo invocationID del database di Servizi di dominio Active Directory, viene eliminato il pool RID e SYSVOL è contrassegnato come non autorevole. Per altre informazioni, vedere Introduzione alla virtualizzazione di Servizi di dominio Active Directory (livello 100) e la pagina relativa alla virtualizzazione sicura di DFSR.

Molti scenari di distribuzione di Servizi di dominio Active Directory di Windows Server sono ideali per la distribuzione di elementi come le VM in Azure. Ad esempio, si supponga di avere una società in Europa in cui occorre autenticare gli utenti di una sede remota in Asia. La società non ha distribuito in precedenza controller di dominio Active Directory di Windows Server in Asia a causa del relativo costo di distribuzione e delle competenze limitate per la gestione della post-distribuzione dei server. Di conseguenza, le richieste di autenticazione dall'Asia vengono soddisfatte dai controller di dominio in Europa con risultati non ottimali. In questo caso, è possibile distribuire un controller di dominio in una VM di cui si è specificato che la relativa esecuzione deve essere effettuata nel data center di Azure in Asia. Il collegamento di questo controller di dominio a una rete virtuale di Azure connessa direttamente alla sede remota determinerà un miglioramento delle prestazioni di autenticazione.

Azure è inoltre ideale come soluzione alternativa a siti di ripristino di emergenza altrimenti costosi. Il costo relativamente basso dell'hosting di un numero esiguo di controller di dominio e di una singola rete virtuale in Azure rappresenta un'alternativa interessante.

Infine, potrebbe essere necessario distribuire un'applicazione di rete in Azure, ad esempio SharePoint, per la quale è richiesto Active Directory di Windows Server ma senza dipendenze dalla rete locale o da Active Directory di Windows Server aziendale. In questo caso, la distribuzione di una foresta isolata in Azure per soddisfare i requisiti del server SharePoint è la soluzione ottimale. Inoltre, è supportata anche la distribuzione di applicazioni di rete per cui è richiesta la connettività alla rete locale e ad Active Directory aziendale.

noteNota
Poiché viene fornita una connessione di livello 3, il componente VPN che offre connettività tra una rete virtuale di Azure e una rete locale può anche abilitare server membri in esecuzione in locale per l'uso di controller di dominio eseguiti come macchine virtuali di Azure in Rete virtuale di Azure. Tuttavia, se il componente VPN non è disponibile, le comunicazioni tra i computer locali e i controller di dominio basati su Azure non funzionano, con la conseguenza di errori di autenticazione e di altra natura.  

  • Per qualsiasi scenario di distribuzione di Active Directory di Windows Server che prevede più di una macchina virtuale, è necessario usare una rete virtuale di Azure per la coerenza degli indirizzi IP. Si noti che in questa guida si presuppone che i controller di dominio siano in esecuzione in una rete virtuale di Azure.

  • Come per i controller di dominio locali, è consigliabile usare indirizzi IP statici. È possibile configurare un indirizzo IP statico solo tramite Azure PowerShell. Vedere la pagina relativa alla configurazione di un indirizzo IP interno statico per una macchina virtuale. Se sono presenti sistemi di monitoraggio o altre soluzioni che ricercano la configurazione di un indirizzo IP statico nel sistema operativo guest, è possibile assegnare lo stesso indirizzo IP statico alle proprietà della scheda di rete della macchina virtuale. Considerare tuttavia che la scheda di rete verrà ignorata se la macchina virtuale viene sottoposta a correzione dei servizi o viene arrestata nel portale di gestione e il relativo indirizzo viene deallocato. In questo caso, l'indirizzo IP statico nel sistema operativo guest dovrà essere reimpostato.

  • La distribuzione di VM in una rete virtuale non implica (né richiede) che venga ristabilita la connettività a una rete locale, infatti questa possibilità viene consentita semplicemente tramite la rete virtuale. È necessario creare una rete virtuale per le comunicazioni private tra Azure e la rete locale. È necessario distribuire un endpoint VPN nella rete locale. La VPN viene aperta da Azure alla rete locale. Per altre informazioni, vedere Panoramica di Rete virtuale e Configurare un VPN da sito a sito nel portale di gestione.

    noteNota
    È disponibile un'opzione per creare una VPN da punto a sito per connettere singoli computer basati su Windows direttamente a una rete virtuale di Azure.

  • Indipendentemente dal fatto che venga creata o meno una rete virtuale, in Azure viene addebitato il traffico in uscita ma non quello in entrata. Le varie opzioni di progettazione di Active Directory di Windows Server possono influire sulla quantità di traffico in uscita generato da una distribuzione. Ad esempio, con la distribuzione di un controller di dominio di sola lettura il traffico in uscita viene limitato perché non viene replicato. La decisione di distribuire un controller di dominio di sola lettura tuttavia deve essere soppesata valutando anche la necessità di eseguire operazioni di scrittura nel controller di dominio e la compatibilità delle applicazioni e dei servizi nel sito con i controller di dominio di sola lettura. Per altre informazioni sugli addebiti per il traffico, vedere Panoramica dei prezzi di Azure.

  • Sebbene si disponga di un controllo completo sulle risorse server da usare per le VM locali, ad esempio la quantità di RAM, le dimensioni del disco e così via, in Azure, è necessario scegliere da un elenco di dimensioni server preconfigurate. Per un controller di dominio, è necessario un disco dati, oltre al disco del sistema operativo, per poter archiviare il database di Active Directory di Windows Server.

Sì, è possibile distribuire ADFS di Windows Server in macchine virtuali di Azure e le procedure consigliate per la distribuzione di ADFS in locale si applicano anche alla distribuzione di ADFS in Azure. Alcune di queste procedure consigliate, ad esempio il bilanciamento del carico e la disponibilità elevata, richiedono tuttavia tecnologie superiori rispetto alle funzionalità offerte da ADFS. Queste devono essere fornite dall'infrastruttura sottostante. Di seguito vengono esaminate alcune delle procedure consigliate e viene descritto come attuarle usando macchine virtuali di Azure e una rete virtuale di Azure.

  1. Non esporre mai i server del servizio token di sicurezza direttamente a Internet.

    Questo è importante poiché il ruolo STS rilascia token di sicurezza. Di conseguenza, i server del servizio token di sicurezza come i server ADFS devono essere gestiti con lo stesso livello di protezione di un controller di dominio. Se un servizio token di sicurezza viene danneggiato, gli utenti malintenzionati hanno la possibilità di rilasciare token di accesso potenzialmente contenenti attestazioni di loro scelta alle applicazioni relying party e ad altri server dei servizi token di sicurezza in organizzazioni attendibili.

  2. Distribuire controller di dominio Active Directory per tutti i domini utente nella stessa rete dei server ADFS.

    I server ADFS usano Servizi di dominio Active Directory per autenticare gli utenti. È consigliabile distribuire controller di dominio sulla stessa rete dei server ADFS. In questo modo, vengono garantite continuità aziendale in caso di interruzione del collegamento tra la rete di Azure e la rete locale, una latenza inferiore e prestazioni migliori per gli account di accesso.

  3. Distribuire più nodi ADFS per disponibilità elevata e bilanciamento del carico.

    Nella maggior parte dei casi, l'errore di un'applicazione abilitata da ADFS non è accettabile perché le applicazioni che richiedono token di sicurezza sono spesso cruciali. Di conseguenza e poiché ADFS svolge un ruolo fondamentale per l'accesso ad applicazioni cruciali, il servizio ADFS deve garantire la disponibilità elevata in più proxy e server ADFS. Per eseguire correttamente la distribuzione delle richieste, il bilanciamento del carico viene in genere distribuito davanti ai proxy e ai server ADFS.

  4. Distribuire uno o più nodi Proxy applicazione Web per l'accesso a Internet.

    Quando gli utenti devono accedere ad applicazioni protette dal servizio ADFS, questo deve essere disponibile da Internet. A questo scopo, viene distribuito il servizio Proxy applicazione Web. Ai fini della disponibilità elevata e del bilanciamento del carico, è altamente consigliabile distribuire più di un nodo.

  5. Limitare l'accesso a risorse di rete interne dai nodi Proxy applicazione Web.

    Per permettere a utenti esterni di accedere ad ADFS da Internet, è necessario distribuire nodi Proxy applicazione Web (o proxy ADFS nelle versioni precedenti di Windows Server). I nodi Proxy applicazione Web sono esposti direttamente a Internet. Non devono necessariamente essere aggiunti al dominio e devono accedere ai server ADFS solo attraverso le porte TCP 443 e 80. È altamente consigliabile bloccare la comunicazione con tutti gli altri computer (in particolare i controller di dominio).

    Questo obiettivo viene in genere realizzato localmente per mezzo di una rete perimetrale. Il funzionamento dei firewall avviene in modalità elenco per limitare il traffico dalla rete perimetrale alla rete locale (è consentito solo il traffico dagli indirizzi IP specificati e su porte specificate, mentre il resto del traffico viene bloccato).

Il diagramma mostra questo comportamento in una distribuzione ADFS locale tradizionale.

ADFS locale con rete perimetrale

Tuttavia, poiché Azure non fornisce funzionalità firewall native complete, è necessario usare altre opzioni per limitare il traffico. La tabella seguente illustra ogni opzione e i suoi vantaggi e svantaggi.

 

Opzione Vantaggi Svantaggi

ACL di rete di Azure

Configurazione iniziale meno costosa e più semplice.

Può essere necessaria la configurazione di altri ACL di rete se vengono aggiunte nuove macchine virtuali alla distribuzione.

Barracuda NG Firewall

Funzionamento in modalità elenco, non richiede alcuna configurazione di ACL di rete.

Costi e complessità maggiori per la configurazione iniziale.

In questo caso, questa è la procedura di alto livello per distribuire ADFS:

  1. Creare una rete virtuale con connettività di più sedi locali usando una VPN o ExpressRoute.

  2. Distribuire controller di dominio nella rete virtuale. Questo passaggio è facoltativo ma consigliato.

  3. Distribuire server ADFS aggiunti a un dominio nella rete virtuale.

  4. Creare un set interno con carico bilanciato che include i server ADFS e che usa un nuovo indirizzo IP privato all'interno della rete virtuale (un DIP).

    1. Aggiornare il DNS per creare l'FQDN in modo da puntare all'indirizzo IP privato (DIP) del set interno con carico bilanciato.

  5. Creare un servizio cloud (o una rete virtuale separata) per i nodi Proxy applicazione Web.

  6. Distribuire i nodi Proxy applicazione Web nel servizio cloud o nella rete virtuale.

    1. Creare un set esterno con carico bilanciato che include i nodi Proxy applicazione Web.

    2. Aggiornare il nome DNS esterno (FQDN) in modo da puntare all'indirizzo IP pubblico del servizio cloud (VIP).

    3. Configurare i proxy ADFS in modo da usare l'FQDN che corrisponde al set interno con carico bilanciato per i server ADFS.

    4. Aggiornare i siti Web basati su attestazioni in modo da usare l'FQDN esterno per il provider di attestazioni.

  7. Limitare l'accesso tra Proxy applicazione Web e qualsiasi computer nella rete virtuale di ADFS.

Per limitare il traffico, il set con carico bilanciato per il bilanciamento del carico interno di Azure deve essere configurato per il solo traffico verso le porte TCP 80 e 443, mentre il resto del traffico verso il DIP interno del set con carico bilanciato deve essere eliminato.

ACL di rete ADFS

Il traffico verso i server ADFS è permesso solo da queste origini:

  • Bilanciamento del carico interno di Azure.

  • Indirizzo IP di un amministratore nella rete locale.

WarningAvviso
La progettazione deve impedire ai nodi Proxy applicazione Web di accedere ad altre macchine virtuali nella rete virtuale di Azure o a qualsiasi percorso nella rete locale. A questo scopo, è possibile configurare regole firewall nel dispositivo locale per le connessioni ExpressRoute o nel dispositivo VPN per le connessioni VPN da sito a sito.

Uno svantaggio di questa opzione è la necessità di configurare gli ACL di rete per più dispositivi, tra cui bilanciamento del carico interno, server ADFS e altri server che vengono aggiunti alla rete virtuale. Se un dispositivo viene aggiunto alla distribuzione senza configurare gli ACL di rete per limitarne il traffico, l'intera distribuzione può essere a rischio. Se gli indirizzi IP dei nodi Proxy applicazione Web cambiano, è necessario reimpostare gli ACL di rete, ovvero i proxy devono essere configurati per l'uso di DIP statici.

ADFS su Azure con ACL di rete

Un'altra opzione consiste nell'usare il dispositivo Barracuda NG Firewall per controllare il traffico tra i server proxy ADFS e i server ADFS. Questa opzione è conforme alle procedure consigliate per la sicurezza e la disponibilità elevata e richiede attività di amministrazione minori dopo l'installazione iniziale perché il dispositivo Barracuda NG Firewall offre una modalità elenco per l'amministrazione del firewall e può essere installato direttamente su una rete virtuale di Azure. In questo modo, viene eliminata la necessità di configurare gli ACL di rete ogni volta che viene aggiunto un nuovo server alla distribuzione. Tuttavia, questa opzione comporta una distribuzione iniziale con maggiori costi e complessità.

In questo caso, vengono distribuite due reti virtuali invece di una. La rete virtuale 1 contiene i proxy, mentre la rete virtuale 2 contiene i servizi token di sicurezza e la connessione di rete alla rete aziendale. Di conseguenza, la rete virtuale 1 è fisicamente (benché virtualmente) isolata dalla rete virtuale 2 e quindi anche dalla rete aziendale. La rete virtuale 1 viene quindi connessa alla rete virtuale 2 usando una tecnologia di tunneling speciale chiamata Transport Independent Network Architecture (TINA). Il tunnel TINA è collegato a ognuna delle reti virtuali mediante un dispositivo Barracuda NG Firewall, uno su ogni rete virtuale.  Per garantire disponibilità elevata, è consigliabile distribuire due dispositivi Barracuda su ogni rete virtuale, uno attivo, l'altro passivo. Questi dispositivi offrono funzionalità firewall complesse che permettono di simulare il funzionamento di una tradizionale rete perimetrale locale in Azure.

ADFS su Azure con firewall

Per altre informazioni, vedere 2. ADFS: estendere in Internet un'applicazione front-end locale in grado di riconoscere attestazioni.

Alternativa alla distribuzione di ADFS, se l'obiettivo è solo SSO di Office 365

Esiste un'altra alternativa alla distribuzione completa di ADFS se l'obiettivo è solo l'abilitazione dell'accesso per Office 365. In questo caso, è semplicemente possibile distribuire DirSync con sincronizzazione delle password in locale e ottenere lo stesso risultato finale con una complessità di distribuzione minima, perché questo approccio non richiede ADFS o Azure.

Nella tabella riportata di seguito vengono confrontati i processi di accesso con e senza distribuzione di ADFS.

 

Punto di accesso singolo a Office 365 usando ADFS e DirSync Stesso punto di accesso singolo a Office 365 usando DirSync + sincronizzazione password
  1. L'utente accede a una rete aziendale e viene autenticato in Active Directory di Windows Server.

  2. L'utente tenta di accedere a Office 365 (nomeutente@contoso.com).

  3. Office 365 reindirizza l'utente ad Active Directory di Azure.

  4. Poiché Azure AD non è in grado di autenticare l'utente e rileva l'esistenza di una relazione affidabile con ADFS in locale, l'utente viene reindirizzato a ADFS

  5. L'utente invia un ticket Kerberos al ruolo STS di ADFS.

  6. ADFS trasforma il ticket Kerberos nell'attestazione/formato di token richiesto e reindirizza l'utente a Azure AD.

  7. L'utente esegue l'autenticazione a Azure AD (si verifica un'ulteriore trasformazione).

  8. Active Directory di Azure reindirizza l'utente a Office 365.

  9. L'utente viene connesso automaticamente a Office 365

  1. L'utente accede a una rete aziendale e viene autenticato in Active Directory di Windows Server.

  2. L'utente tenta di accedere a Office 365 (nomeutente@contoso.com).

  3. Office 365 reindirizza l'utente ad Active Directory di Azure.

  4. Azure AD non può accettare direttamente i ticket Kerberos e non esiste alcuna relazione di trust, pertanto richiede che l'utente immetta le credenziali.

  5. L'utente immette la stessa password locale e Azure AD la convalida rispetto al nome utente e alla password sincronizzata tramite DirSync.

  6. Active Directory di Azure reindirizza l'utente a Office 365.

  7. L'utente può accedere a Office 365 e OWA usando il token di Active Directory di Azure.

In Office 365 con uno scenario DirSync con sincronizzazione delle password (non ADFS), Single Sign-On è sostituito da "Same Sign-On", dove "same" indica semplicemente che gli utenti devono immettere di nuovo le stesse credenziali locali per accedere a Office 365. Questi dati possono essere memorizzati dal browser dell'utente per ridurre le richieste successive.

Ulteriori riflessioni

  • Se si distribuisce un proxy ADFS in una macchina virtuale di Azure, è necessario disporre di connettività ai server ADFS. Se i server sono locali, è consigliabile usare la connettività VPN da sito a sito fornita dalla rete virtuale per permettere ai nodi Proxy applicazione Web di comunicare con i server ADFS.

  • Se si distribuisce un server ADFS in una macchina virtuale di Azure, è necessario disporre di connettività ai controller di dominio Active Directory di Windows Server, agli archivi di attributi e ai database di configurazione e può anche essere necessario ExpressRoute o una connessione VPN da sito a sito tra la rete virtuale di Azure e la rete locale.

  • Gli addebiti vengono applicati a tutto il traffico in uscita dalle macchine virtuali di Azure. Se il costo è un fattore determinante, è consigliabile distribuire i nodi Proxy applicazione Web su Azure, lasciando i server ADFS in locale. Se i server ADFS vengono distribuiti anche in macchine virtuali di Azure, sarà necessario sostenere costi aggiuntivi per autenticare gli utenti locali. Il traffico in uscita comporta un costo indipendentemente dal fatto che avvenga attraverso ExpressRoute o la connessione VPN da sito a sito.

  • Se si sceglie di usare le funzionalità di bilanciamento del carico dei server native di Azure per la disponibilità elevata dei server ADFS, il bilanciamento del carico offre probe che permettono di determinare l'integrità delle macchine virtuali nel servizio cloud. Nel caso di macchine virtuali di Azure (invece di ruoli Web o di lavoro), è necessario usare un probe personalizzato perché l'agente che risponde ai probe predefiniti non è presente nelle macchine virtuali di Azure. Per semplicità, è possibile usare un probe TCP personalizzato. A questo scopo, è solo necessario stabilire correttamente una connessione TCP (un segmento TCP SYN inviato e una risposta con un segmento TCP SYN ACK) per determinare l'integrità della macchina virtuale. È possibile configurare il probe personalizzato per l'uso di qualsiasi porta TCP su cui le macchine virtuali sono attivamente in ascolto. A questo scopo, vedere Configurare un set con carico bilanciato.

    noteNota
    Nelle macchine in cui è necessario esporre lo stesso set di porte direttamente in Internet, ad esempio le porte 80 e 443, non è possibile la condivisione dello stesso servizio cloud. Pertanto, è consigliabile creare un servizio cloud dedicato per i server ADFS di Windows Server in uso per evitare possibili sovrapposizioni tra i requisiti di porta per un'applicazione e ADFS di Windows Server.

Nella sezione seguente vengono descritti scenari di distribuzione comuni in cui vengono evidenziate considerazioni importanti di cui tener conto. In ogni scenario sono disponibili collegamenti a ulteriori dettagli sulle decisioni e sui fattori da considerare.

Distribuzione Servizi di dominio Active Directory solo cloud

Figura 1

SharePoint è distribuito in una macchina virtuale di Azure e l'applicazione è priva di dipendenze dalle risorse della rete aziendale. Per l'applicazione è necessario Servizi di dominio Active Directory di Windows Server ma non Servizi di dominio Active Directory di Windows Server aziendale. Non sono richiesti né trust Kerberos né trust federativi perché il provisioning degli utenti viene effettuato automaticamente tramite l'applicazione nel dominio di Servizi di dominio Active Directory di Windows Server che è ospitato anche nel cloud nelle macchine virtuali di Azure.

  • Topologia di rete: creare una rete virtuale di Azure senza connettività tra più sedi locali (nota anche come connettività da sito a sito).

  • Configurazione della distribuzione del controller di dominio: distribuire un nuovo controller di dominio in un nuova foresta Active Directory di Windows Server a dominio singolo. Questa soluzione deve essere distribuita insieme al server DNS Windows.

  • Topologia del sito Active Directory di Windows Server: usare il sito Active Directory di Windows Server predefinito (il valore predefinito di tutti i computer è Nome-predefinito-primo-sito)

  • Impostazione indirizzi IP e DNS:

    • impostare un indirizzo IP statico per il controller di dominio usando il cmdlet di Azure PowerShell Set-AzureStaticVNetIP.

    • Installare e configurare il DNS di Windows Server nei controller di dominio in Azure.

    • Configurare le proprietà della rete virtuale con il nome e l'indirizzo IP della macchina virtuale che ospita i ruoli del server Controller di dominio e DNS.

  • Catalogo globale: il primo controller di dominio nella foresta deve essere un server di catalogo globale. Devono inoltre essere configurati controller di dominio aggiuntivi come cataloghi globali perché in una foresta a dominio singolo. Per il catalogo globale non sono richieste operazioni aggiuntive da parte del controller di dominio.

  • Posizione del database di Servizi di dominio Active Directory di Windows Server e di SYSVOL: aggiungere un disco dati ai controller di dominio in esecuzione come macchine virtuali di Azure per poter archiviare SYSVOL, i log e il database di Active Directory di Windows Server.

  • Backup e ripristino: determinare la posizione in cui archiviare i backup dello stato del sistema. Se necessario, aggiungere un altro disco dati alla VM del controller di dominio per l'archiviazione dei backup.

Federazione con connettività di più sedi locali

Figura 2

Un'applicazione in grado di riconoscere attestazioni distribuita correttamente in locale e usata dagli utenti aziendali deve essere accessibile direttamente da Internet. L'applicazione viene usata come front-end Web in un database SQL in cui vengono archiviati e recuperati i dati. I server SQL usati dall'applicazione sono inoltre presenti nella rete aziendale. Per fornire l'accesso agli utenti aziendali, sono stati distribuiti in locale due ruoli STS ADFS di Windows Server e un servizio di bilanciamento del carico. A questo punto, l'accesso all'applicazione direttamente su Internet deve essere garantito sia ai partner aziendali tramite le relative identità aziendali sia agli utenti aziendali esistenti.

Per semplificare e soddisfare le esigenze di configurazione e distribuzione di questo nuovo requisito, si è deciso di installare due front-end Web aggiuntivi e due server proxy ADFS di Windows Server nelle macchine virtuali di Azure. Queste quattro VM verranno tutte esposte direttamente in Internet e verrà fornita la connettività alla rete locale tramite la funzionalità VPN da sito a sito della rete virtuale di Azure.

  • Topologia di rete: creare una rete virtuale di Azure e configurare la connettività tra più sedi locali.

    noteNota
    Per ognuno dei certificati di ADFS di Windows Server, verificare che l'URL definito nel modello di certificato e nei certificati risultanti sia raggiungibile da istanze di ADFS di Windows Server in esecuzione in Azure. È possibile che per questa condizione sia richiesta la connettività tra più sedi locali a parti dell'infrastruttura PKI. Ad esempio, se l'endpoint di CRL è basato su LDAP e ospitato esclusivamente in locale, sarà necessaria la connettività tra più sedi locali. Se ciò non è opportuno, può essere necessario usare i certificati emessi da un'autorità di certificazione i cui CRL sono accessibili su Internet.

  • Configurazione di servizi cloud: assicurarsi di disporre di due servizi cloud per poter fornire due indirizzi VIP con bilanciamento del carico. L'indirizzo VIP del primo servizio cloud verrà indirizzato alle due macchine virtuali del proxy ADFS di Windows Server sulle porte 80 e 443. Le macchine virtuali del proxy ADFS di Windows Server verranno configurate per puntare all'indirizzo IP del bilanciamento del carico locale usato dai servizi token di sicurezza di ADFS di Windows Server. L'indirizzo VIP del secondo servizio cloud verrà indirizzato alle due macchine virtuali che eseguono il front-end Web sempre sulle porte 80 e 443. Configurare un probe personalizzato per assicurarsi che il bilanciamento del carico indirizzi il traffico solo al proxy ADFS di Windows Server e alle macchine virtuali front-end Web funzionanti.

  • Configurazione del server federativo: configurare ADFS di Windows Server come server federativo (, STS, servizio token di sicurezza) per generare token di sicurezza per la foresta Active Directory di Windows Server creata nel cloud. Impostare le relazioni di trust del provider di attestazioni della federazione con i diversi partner da cui si desidera accettare le identità e configurare le relazioni di trust di relying party con le varie applicazioni in cui desidera si generare i token.

    Nella maggior parte degli scenari i server proxy ADFS di Windows Server vengono distribuiti in una soluzione con connessione Internet per motivi di sicurezza, mentre le relative controparti della federazione ADFS di Windows Server rimangono isolate dalla connettività Internet diretta. Indipendentemente dallo scenario di distribuzione, è necessario configurare il servizio cloud in uso con un indirizzo VIP che fornirà un indirizzo IP esposto pubblicamente e una porta tramite cui verrà bilanciato il carico tra le due istanze STS ADFS di Windows Server o le istanze proxy.

  • Configurazione della disponibilità elevata di ADFS di Windows Server: è consigliabile distribuire una farm di ADFS di Windows Server con almeno due server per il failover e il bilanciamento del carico. Si valuti la possibilità di usare Database interno di Windows per i dati di configurazione di ADFS di Windows Server e usare la funzionalità di bilanciamento del carico interno di Azure per distribuire le richieste in entrata nei server della farm.

    Per altre informazioni, vedere la pagina relativa alla guida alla distribuzione di Servizi di dominio Active Directory.

Distribuzione Servizi di dominio Active Directory tra sedi locali

Figura 3

Un'applicazione LDAP, che supporta l'autenticazione integrata di Windows e in cui Servizi di dominio Active Directory di Windows Server viene usato come archivio per i dati di configurazione e del profilo utente, viene distribuita in una macchina virtuale di Azure. È consigliabile che nell'applicazione si utilizzi Servizi di dominio Active Directory di Windows Server aziendale esistente e che venga fornito l'accesso Single Sign-On. L'applicazione non è in grado di riconoscere attestazioni. Inoltre, gli utenti devono accedere all'applicazione direttamente da Internet. Per ottimizzare le prestazioni e i costi, si è deciso di distribuire due controller di dominio aggiuntivi, che fanno parte del dominio aziendale, insieme all'applicazione in Azure.

  • Topologia di rete: creare una rete virtuale di Azure con connettività tra più sedi locali.

  • Metodo di installazione: distribuire controller di dominio di replica dal dominio Active Directory di Windows Server aziendale. Per un controller di dominio di replica, è possibile installare Servizi di dominio Active Directory di Windows Server nella VM e, facoltativamente, usare la funzionalità Installazione da supporto per ridurre la quantità di dati che devono essere replicati nel nuovo controller di dominio durante l'installazione. Per un'esercitazione, vedere Installare un controller di dominio Active Directory di replica in Azure. Anche se si usa Installazione da supporto, potrebbe essere più conveniente compilare il controller di dominio virtuale in locale e spostare l'intero disco rigido virtuale nel cloud anziché replicare Servizi di dominio Active Directory di Windows Server durante l'installazione. Per motivi di sicurezza, è consigliabile eliminare il disco rigido virtuale dalla rete locale una volta eseguita la copia in Azure.

  • Topologia del sito Active Directory di Windows Server: creare un nuovo sito di Azure in Siti e servizi di Active Directory. Creare un oggetto subnet di Active Directory di Windows Server per rappresentare la rete virtuale di Azure e aggiungere la subnet al sito. Creare un nuovo collegamento di sito che preveda il nuovo sito di Azure e il sito in cui si trova l'endpoint VPN della rete virtuale di Azure per controllare e ottimizzare il traffico di Active Directory di Windows Server da e verso Azure.

  • Impostazione indirizzi IP e DNS:

    • impostare un indirizzo IP statico per il controller di dominio usando il cmdlet di Azure PowerShell Set-AzureStaticVNetIP.

    • Installare e configurare il DNS di Windows Server nei controller di dominio in Azure.

    • Configurare le proprietà della rete virtuale con il nome e l'indirizzo IP della macchina virtuale che ospita i ruoli del server Controller di dominio e DNS.

  • Controller di dominio geograficamente distribuiti: configurare reti virtuali aggiuntive in base alle esigenze. Se la topologia dei siti di Active Directory richiede la presenza di controller di dominio in aree geografiche che corrispondono a diverse regioni di Azure, è possibile creare siti di Active Directory corrispondenti.

  • Controller di dominio di sola lettura: è possibile distribuire un controller di dominio di sola lettura nel sito di Azure, a seconda dei requisiti per l'esecuzione di operazioni di scrittura nel controller di dominio e della compatibilità di applicazioni e servizi nel sito con controller di dominio di sola lettura. Per altre informazioni sulla compatibilità delle applicazioni, vedere Compatibilità delle applicazioni con i controller di dominio di sola lettura.

  • Catalogo globale: i cataloghi globali sono necessari per soddisfare le richieste di accesso in foreste con più domini. Se non si distribuisce un catalogo globale nel sito di Azure, si incorrerà in costi di traffico di uscita, dal momento che tramite le richieste di autenticazione vengono generate query sui cataloghi globali in altri siti. Per ridurre il traffico, è possibile abilitare la funzionalità caching appartenenza a gruppo universale per il sito di Azure in Siti e servizi di Active Directory.

    Se si distribuisce un catalogo globale, configurare i collegamenti di sito e i relativi costi in modo che il catalogo globale nel sito di Azure non sia scelto come controller di dominio di origine preferito da altri cataloghi globali per cui devono essere replicate le stesse partizioni di dominio parziali.

  • Posizione del database di Servizi di dominio Active Directory di Windows Server e di SYSVOL: aggiungere un disco dati ai controller di dominio in esecuzione in macchine virtuali di Azure per poter archiviare SYSVOL, i log e il database di Active Directory di Windows Server.

  • Backup e ripristino: determinare la posizione in cui archiviare i backup dello stato del sistema. Se necessario, aggiungere un altro disco dati alla VM del controller di dominio per l'archiviazione dei backup.

Nella tabella riportata di seguito sono riepilogate le aree tecnologiche di Active Directory di Windows Server che sono state prese in considerazione negli scenari precedenti con le relative decisioni di cui tener conto e i collegamenti a informazioni più dettagliate. È possibile che alcune aree tecnologiche non siano applicabili a tutti gli scenari di distribuzione e che alcune di queste aree siano più critiche in uno scenario di distribuzione rispetto ad altre.

Ad esempio, se si distribuisce un controller di dominio di replica in una rete virtuale e la foresta dispone di un solo dominio, la scelta di distribuire un server di catalogo globale in questo caso non sarà critica per lo scenario di distribuzione perché non creerà requisiti di replica aggiuntivi. D'altra parte, se la foresta dispone di diversi domini, la decisione di distribuire un catalogo globale in una rete virtuale potrebbe influire sulla larghezza di banda disponibile, sulle prestazioni, sull'autenticazione, sulle ricerche nella directory e così via.

 

Numero elemento

Area tecnologica di Active Directory di Windows Server

Decisioni

Fattori

1

Topologia di rete

Creare una rete virtuale?

Requisiti per l'accesso alle risorse aziendali

Autenticazione

Gestione account

2

Configurazione della distribuzione del controller di dominio

  • Distribuire una foresta separata senza trust?

  • Distribuire una nuova foresta con federazione?

  • Distribuire una nuova foresta con trust tra foreste Active Directory di Windows Server per Kerberos?

  • Estendere la foresta aziendale distribuendo un controller di dominio di replica?

  • Estendere la foresta aziendale distribuendo un nuovo dominio figlio o albero di dominio?

Sicurezza

Conformità

Costo

Resilienza e tolleranza di errore

Compatibilità dell'applicazione

3

Topologia del sito Active Directory di Windows Server

In che modo configurare subnet, siti e collegamenti di sito con Rete virtuale di Azure per ottimizzare il traffico e ridurre il costo?

Definizioni di sito e di subnet

Proprietà di collegamenti di sito e notifica di modifiche

Compressione della replica

4

Impostazione indirizzi IP e DNS

Come configurare gli indirizzi IP e la risoluzione dei nomi?

Usare il cmdlet Set-AzureStaticVNetIP per assegnare un indirizzo IP statico.

Installare il server DNS di Windows Server e configurare le proprietà della rete virtuale con il nome e l'indirizzo IP della macchina virtuale che ospita i ruoli server DNS e controller di dominio.

5

Controller di dominio geograficamente distribuiti

Come eseguire la replica in controller di dominio in reti virtuali separate?

Se la topologia dei siti di Active Directory richiede la presenza di controller di dominio in aree geografiche che corrispondono a diverse regioni di Azure, è possibile creare siti di Active Directory corrispondenti. Configurare la connettività tra reti virtuali per eseguire la replica tra controller di dominio in reti virtuali separate.

6

Controller di dominio di sola lettura

Usare controller di dominio di sola lettura o scrivibili?

Filtrare attributi HBI/PII

Filtrare segreti

Limitare il traffico in uscita

7

Catalogo globale

Installare il catalogo globale?

Per una foresta a dominio singolo, creare tutti i cataloghi globali dei controller di dominio

Per una foresta a più domini, i cataloghi globali sono necessari per l'autenticazione

8

Metodo di installazione

Come installare un controller di dominio in Azure?

  • Installare Servizi di dominio Active Directory tramite Windows PowerShell o Dcpromo

-oppure-

  • Spostare il disco rigido virtuale di un controller di dominio virtuale locale

9

Posizione del database di Servizi di dominio Active Directory di Windows Server e di SYSVOL

Dove archiviare il database di Servizi di dominio Active Directory di Windows Server, i log e SYSVOL?

Modificare i valori predefiniti di Dcpromo.exe

ImportantImportante
Questi file di Active Directory critici DEVONO essere posizionati nei dischi dati di Azure anziché nei dischi del sistema operativo tramite cui viene implementato il caching in scrittura.

10

Backup e ripristino

Come proteggere e recuperare i dati?

Creare backup dello stato del sistema

11

Configurazione del server federativo

Distribuire una nuova foresta con federazione nel cloud?

Distribuire ADFS in locale ed esporre un proxy nel cloud?

Sicurezza

Conformità

Costo

Accesso alle applicazioni da partner aziendali

12

Configurazione di servizi cloud

Un servizio cloud viene distribuito in modo implicito alla prima creazione di una macchina virtuale. È necessario distribuire servizi cloud aggiuntivi?

Per le VM è necessaria l'esposizione diretta in Internet?

Per il servizio è richiesto il bilanciamento del carico?

13

Requisiti del server federativo per l'impostazione degli indirizzi IP pubblici e privati (confronto tra indirizzi DIP e VIP)

L'istanza di ADFS di Windows Server deve essere raggiunta direttamente da Internet?

Per l'applicazione distribuita nel cloud sono necessari il proprio indirizzo IP con connessione Internet e la porta?

Creare un servizio cloud per ogni indirizzo IP virtuale richiesto dalla distribuzione

14

Configurazione della disponibilità elevata di ADFS di Windows Server

Quanti nodi è opportuno distribuire nella server farm di ADFS di Windows Server?

Quanti nodi è opportuno distribuire nella farm del proxy ADFS di Windows Server?

Resilienza e tolleranza di errore

Per poter soddisfare i requisiti di DNS e di coerenza degli indirizzi IP di Servizi di dominio Active Directory di Windows Server, è necessario innanzitutto creare la rete virtuale di Azure a cui collegare le macchine virtuali. Durante la relativa creazione, è necessario stabilire se estendere facoltativamente la connettività alla rete aziendale locale, tramite cui le macchine virtuali di Azure vengono connesse in modo trasparente alle macchine locali. A tale scopo vengono usate le tecnologie VPN tradizionali e viene richiesta l'esposizione di un endpoint VPN sul perimetro della rete aziendale. In altre parole, la rete VPN viene avviata da Azure alla rete aziendale, non viceversa.

Si noti che, oltre agli addebiti standard per ciascuna VM, vengono applicate spese aggiuntive quando si estende una rete virtuale alla rete locale. In particolare, vi sono addebiti per il tempo CPU del gateway della rete virtuale di Azure e per il traffico in uscita generato dalle comunicazioni di ciascuna VM con le macchine locali nella VPN. Per altre informazioni sugli addebiti per il traffico di rete, vedere Panoramica dei prezzi di Azure.

La modalità di configurazione del controller di dominio dipende dai requisiti per il servizio che si desidera eseguire in Azure. Ad esempio, è possibile distribuire una nuova foresta, isolata dalla propria foresta aziendale, per testare un modello di prova, una nuova applicazione o alcuni altri progetti a breve termine per cui sono richiesti servizi directory ma non l'accesso specifico a risorse aziendali interne.

Il vantaggio derivante dalla mancata replica di un controller di dominio di una foresta isolata con i controller di dominio locali consente di ridurre il traffico di rete in uscita generato dal sistema stesso e, di conseguenza, i costi. Per altre informazioni sugli addebiti per il traffico di rete, vedere Panoramica dei prezzi di Azure.

Sempre a titolo di esempio, si supponga che esistano requisiti di privacy per un servizio, ma che quest'ultimo dipenda dall'accesso ad Active Directory di Windows Server interno. Se è consentito l'hosting dei dati per il servizio nel cloud, è possibile distribuire un nuovo dominio figlio per la foresta interna in Azure. In questo caso, è possibile distribuire un controller di dominio per il nuovo dominio figlio (senza il catalogo globale per risolvere problemi relativi alla privacy). Per questo scenario, insieme alla distribuzione di un controller di dominio di replica, è necessaria una rete virtuale per la connettività ai controller di dominio locali.

Se si crea una nuova foresta, scegliere se usare trust di Active Directory o trust federativi. Bilanciare i requisiti determinati dalla compatibilità, dalla sicurezza, dalla conformità, dal costo e dalla resilienza. Ad esempio, per ottimizzare l'autenticazione selettiva, è possibile scegliere di distribuire una nuova foresta in Azure e creare trust di Active Directory di Windows Server tra la foresta locale e quella cloud. Se l'applicazione è in grado di riconoscere attestazioni, tuttavia, è possibile distribuire trust federativi anziché trust tra foreste Active Directory. Un altro fattore da considerare sarà il costo per la replica di più dati estendendo Active Directory di Windows Server locale nel cloud o per la generazione di più traffico in uscita come risultato dell'autenticazione e del carico di query.

Anche i requisiti di disponibilità e tolleranza di errore influiscono sulla scelta. Ad esempio, se il collegamento viene interrotto, è possibile che lo siano anche le applicazioni in cui viene usato un trust Kerberos o un trust federativo, a meno che non sia stata distribuita un'infrastruttura sufficiente in Azure. Tramite le configurazioni di distribuzione alternative come i controller di dominio di replica (controller di dominio di sola lettura o scrivibili) viene aumentata la probabilità di tolleranza di malfunzionamenti del collegamento.

È necessario definire correttamente i siti e i collegamenti di sito per ottimizzare il traffico e ridurre i costi. I siti, i collegamenti di sito e le subnet influiscono sulla topologia di replica tra i controller di dominio e il flusso del traffico di autenticazione. Si considerino i seguenti addebiti di traffico e, successivamente, distribuire e configurare i controller di dominio in base ai requisiti del proprio scenario di distribuzione:

  • Esiste una tariffa nominale per ora per il gateway stesso:

    • Può essere avviato e arrestato nel modo desiderato

    • Se arrestato, le VM di Azure sono isolate dalla rete aziendale

  • Il traffico in ingresso è gratuito

  • Il traffico in uscita viene addebitato in base alla Panoramica dei prezzi di Azure. È possibile ottimizzare le proprietà dei collegamenti di sito tra i siti locali e siti del cloud come riportato di seguito:

    • Se si usano più reti virtuali, configurare i collegamenti di sito e i relativi costi in modo appropriato per impedire che tramite Servizi di dominio Active Directory di Windows Server venga assegnata la priorità al sito di Azure rispetto a uno tramite cui possono essere forniti gli stessi livelli di servizio gratuitamente. È inoltre possibile prendere in considerazione la disabilitazione dell'opzione relativa al collegamento tramite bridge dei collegamenti di sito (abilitata per impostazione predefinita). In questo modo viene garantito che la replica con un altro sito riguarda solo i siti connessi direttamente. Nei controller di dominio in siti connessi in modo transitivo la replica non può più essere eseguita in modo reciproco e diretto, bensì tramite i siti comuni. Se per qualche motivo i siti intermedi non sono disponibili, la replica tra controller di dominio in siti connessi in modo transitivo non verrà eseguita anche se vi è connettività tra i siti. Infine, laddove sezioni di comportamento di replica transitiva rimangono utili, creare bridge di collegamenti di sito contenenti siti e collegamenti di sito appropriati, ad esempio siti di rete aziendale e in locale.

    • Configurare i costi di collegamento di sito in modo appropriato per evitare traffico imprevisto. Ad esempio, se è abilitata l'opzione Prova sito più vicino successivo, assicurarsi che i siti della rete virtuale non siano tra quelli più vicini successivi aumentando il costo associato dell'oggetto relativo al collegamento di sito tramite cui il sito di Azure viene riconnesso alla rete aziendale.

    • Configurare gli intervalli di collegamento di sito e le pianificazioni in base ai requisiti di coerenza e alla frequenza di modifiche dell'oggetto. Allineare la pianificazione di replica alla tolleranza della latenza. Tramite i controller di dominio viene replicato solo l'ultimo stato di un valore, pertanto la riduzione dell'intervallo di replica può consentire una diminuzione dei costi se la frequenza di modifiche dell'oggetto è sufficiente.

  • Se la riduzione dei costi è una priorità, assicurarsi che la replica venga pianificata e che la notifica di modifiche non sia abilitata. Si tratta della configurazione predefinita per la replica tra siti. Ciò non è importante se si distribuisce un controller di dominio di sola lettura in una rete virtuale perché tramite questo tipo di controller non verranno replicate le modifiche in uscita. Tuttavia, se si distribuisce un controller di dominio scrivibile, assicurarsi che il collegamento di sito non sia configurato per la replica di aggiornamenti con frequenza non necessaria. Se si distribuisce un server di catalogo globale, verificare che tramite tutti gli altri siti in cui è contenuto un catalogo globale vengano replicate le partizioni di dominio da un controller di dominio di origine in un sito che è connesso con collegamenti di sito aventi un costo inferiore rispetto al catalogo globale nel sito di Azure.

  • È possibile ridurre ancora ulteriormente il traffico di rete generato dalla replica tra siti modificando l'algoritmo di compressione della replica. L'algoritmo di compressione è controllato dall'algoritmo di compressione HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Replicator della voce del Registro di sistema REG_DWORD. Il valore predefinito è 3, che è correlato all'algoritmo di compressione Xpress. È possibile impostare il valore su 2, che modifica l'algoritmo in MSZip. Nella maggior parte dei casi, ciò comporta un aumento della compressione, ma a spese dell'utilizzo della CPU. Per altre informazioni, vedere la pagina relativa al funzionamento della topologia di replica di Active Directory.

Alle macchine virtuali di Azure vengono allocati "indirizzi con lease DHCP" per impostazione predefinita. Poiché gli indirizzi dinamici della rete virtuale di Azure sono persistenti con una macchina virtuale per la durata della macchina virtuale stessa, i requisiti di Servizi di dominio Active Directory di Azure vengono soddisfatti.

Pertanto, quando si usa un indirizzo dinamico in Azure, si usa di fatto un indirizzo IP statico poiché è indirizzabile per il periodo del lease, che a sua volta equivale alla durata del servizio cloud.

Se, tuttavia, la macchina virtuale viene arrestata, il relativo indirizzo IP dinamico viene deallocato. Per evitare che l'indirizzo IP venga deallocato, è possibile usare il cmdlet Set-AzureStaticVNetIP per assegnare un indirizzo IP statico.

Per la risoluzione dei nomi, distribuire la propria infrastruttura del server DNS (o usare quella esistente); il DNS fornito da Azure non soddisfa i requisiti avanzati di risoluzione dei nomi di Servizi di dominio Active Directory di Windows Server. Ad esempio, non supporta i record SRV dinamici e così via. La risoluzione dei nomi è un elemento di configurazione critico per i controller di domino e i client di dominio. I controller di dominio devono essere in grado di registrare i record di risorse e di risolvere altri record di risorse del controller di dominio.

Per motivi di prestazioni e tolleranza di errore, la soluzione ottimale consiste nell'installare il servizio DNS di Windows Server nei controller di dominio in esecuzione in Azure. Configurare quindi le proprietà della rete virtuale con il nome e l'indirizzo IP del server DNS. All'avvio di altre macchine virtuali nella rete virtuale, vengono configurate le relative impostazioni di resolver client DNS con il server DNS come parte dell'allocazione dinamica di indirizzi IP dinamici.

noteNota
Non è possibile unire i computer locali a un dominio Active Directory di Servizi di dominio Active Directory di Windows Server ospitato in Azure direttamente su Internet. I requisiti della porta per Active Directory e l'operazione di aggiunta al dominio non consentono di esporre direttamente le porte necessarie e, di fatto, un controller di dominio intero, a Internet.

Tramite le VM viene registrato il relativo nome DNS automaticamente all'avvio o in caso di modifica di un nome.

Per altre informazioni su questo esempio e su un altro in cui viene illustrato il provisioning della prima macchina virtuale e l'installazione in quest'ultima di Servizi di dominio Active Directory, vedere Installazione di una nuova foresta Active Directory in Azure. Per altre informazioni sull'uso di Windows PowerShell, vedere l'introduzione ad Azure PowerShell e la pagina relativa ai cmdlet di gestione di Azure.

Azure offre dei vantaggi quando si ospitano più controller di dominio in reti virtuali diverse:

  • Tolleranza di errore multisito

  • Prossimità fisica alle succursali (latenza più bassa)

Per informazioni sulla configurazione della comunicazione diretta tra reti virtuali, vedere Configurare la connettività tra reti virtuali.

È necessario scegliere se distribuire controller di dominio scrivibili o di sola lettura. Si potrebbe pensare di distribuire controller di dominio di sola lettura in quanto non si avrà un controllo fisico su di essi, ma questi controller sono progettati per essere distribuiti nelle sedi in cui la sicurezza fisica non è sufficiente, ad esempio le succursali.

Azure non presenta il rischio di sicurezza fisica di una succursale, tuttavia i controller di dominio di sola lettura potrebbero comunque risultare più economici dal momento che le funzionalità che forniscono sono particolarmente adatte a questi ambienti, anche se per motivi molto diversi. Ad esempio, i controller di dominio di sola lettura non presentano alcuna replica in uscita e permettono di popolare selettivamente i segreti (password). Per contro, la mancanza di questi segreti potrebbe richiedere traffico in uscita su richiesta per la relativa convalida al momento dell'autenticazione da parte di un utente o di un computer. Tuttavia i segreti possono essere prepopolati e memorizzati nella cache in modo selettivo.

I controller di dominio di sola lettura forniscono un vantaggio aggiuntivo per quanto riguarda i problemi di PII e HBI, poiché è possibile aggiungere attributi contenenti dati sensibili al set di attributi con filtro per controller di dominio di sola lettura. Il set di attributi con filtro è un set personalizzabile di attributi che non vengono replicati nei controller di dominio di sola lettura. È possibile usare il set di attributi con filtro come strumento di sicurezza qualora non sia possibile o non si desideri archiviare PII o HBI in Azure. Per altre informazioni, vedere la pagina relativa al set di attributi con filtro per controller di dominio di sola lettura.

Verificare che le applicazioni siano compatibili con i controller di dominio di sola lettura che si intende usare. Molte applicazioni abilitate per Active Directory di Windows Server funzionano bene con i controller di dominio di sola lettura, ma l'esecuzione di alcune di queste può risultare inefficiente o non riuscire se non dispongono dell'accesso a un controller di dominio scrivibile. Per altre informazioni, vedere Compatibilità delle applicazioni con i controller di dominio di sola lettura.

È necessario scegliere se installare un catalogo globale. In una foresta a dominio singolo è necessario configurare tutti i controller di dominio come server di catalogo globale. I costi non aumenteranno perché non vi sarà alcun traffico di replica aggiuntivo.

In una foresta a più domini, i cataloghi globali sono necessari per espandere le appartenenze a gruppi universali durante il processo di autenticazione. Se non si distribuisce un catalogo globale, i carichi di lavoro nella rete virtuale tramite cui viene eseguita l'autenticazione in un controller di dominio in Azure genereranno indirettamente traffico di autenticazione in uscita per l'esecuzione di query sui cataloghi globali locali durante ogni tentativo di autenticazione.

I costi associati ai cataloghi globali sono meno prevedibili perché in essi viene ospitato ogni dominio (in parte). Se tramite il carico di lavoro viene ospitato un servizio con connessione Internet e vengono autenticati gli utenti in Servizi di dominio Active Directory di Windows Server, potrebbe essere difficile calcolare i costi. Per ridurre le query dei cataloghi globali al di fuori del sito cloud durante l'autenticazione, è possibile abilitare la funzionalità caching appartenenza a gruppo universale.

È necessario scegliere come installare i controller di dominio nella rete virtuale:

Usare solo Macchine virtuali di Azure per i controller di dominio (anziché macchine virtuali del ruolo "Web" o "di lavoro" di Azure). Sono durevoli e la durabilità di stato per un controller di dominio è essenziale. Le macchine virtuali di Azure sono progettate per i carichi di lavoro, ad esempio i controller di dominio.

Non usare SYSPREP per distribuire o clonare i controller di dominio. La possibilità di clonare i controller di dominio è disponibile solo a partire da Windows Server 2012. Per la funzionalità di clonazione è necessario il supporto per VMGenerationID nell'hypervisor sottostante. Hyper-V in Windows Server 2012 e le reti virtuali di Azure supportano entrambi VMGenerationID, così come i fornitori di software di virtualizzazione di terze parti.

Selezionare dove posizionare il database di Servizi di dominio Active Directory di Windows Server, i log e SYSVOL. Devono essere distribuiti nei dischi dati di Azure.".

noteNota
Le dimensioni dei dischi dati di Azure sono vincolate a 1 TB.

Per impostazione predefinita, nelle unità disco dati non vengono memorizzate nella cache le scritture. Nelle unità disco dati collegate a una macchina virtuale viene usata la funzionalità cache write-through. Il caching write-through assicura il commit della scrittura nell'archiviazione di Azure durevole prima del completamento della transazione dal punto di vista del sistema operativo della macchina virtuale. Garantisce durabilità, a spese di scritture leggermente più lente.

Questo aspetto è importante per Servizi di dominio Active Directory di Windows Server perché con il caching su disco write-behind vengono invalidate le interpretazioni del controller di dominio. Tramite Servizi di dominio Active Directory di Windows Server viene tentata la disabilitazione del caching in scrittura ma è responsabilità del sistema di I/O su disco rispettarla. La mancata possibilità di disabilitazione del caching in scrittura può, in determinate circostanze, introdurre il rollback USN causando oggetti residui e altri problemi.

Le procedure consigliate per i controller di dominio virtuali prevedono quanto segue:

  • Impostare Preferenze cache dell'host del disco dati di Azure su NESSUNA. In questo modo si evitano problemi di memorizzazione nella cache di scrittura per le operazioni di Servizi di dominio Active Directory.

  • Archiviare il database, i log e SYSVOL nello stesso disco dati o in dischi dati separati. In genere, si tratta di un disco separato da quello usato per il sistema operativo stesso. L'aspetto più importante è che il database di Servizi di dominio Active Directory di Windows Server e SYSVOL non devono essere archiviati in un tipo di disco del sistema operativo Azure. Per impostazione predefinita, tramite il processo di installazione di Servizi di dominio Active Directory di Windows Server questi componenti vengono installati nella cartella %systemroot% e questa soluzione NON è consigliata per Azure.

Si tenga presente quali elementi sono o meno supportati per il backup e ripristino di un controller di dominio in generale e, più in particolare, quelli in esecuzione in una VM. Vedere Considerazioni sul backup e il ripristino dei controller di dominio virtualizzati.

Creare backup dello stato del sistema usando solo software per backup che riconosca specificatamente i requisiti di backup per Servizi di dominio Active Directory di Windows Server, ad esempio Windows Server Backup.

Non copiare o clonare file VHD di controller di dominio anziché eseguire backup regolari. Se si presenta la necessità di un ripristino, e l'operazione viene eseguita usando VHD clonati o copiati senza Windows Server 2012 e un hypervisor supportato, verranno introdotte bolle USN.

La configurazione di server federativi ADFS di Windows Server (STS) dipende in parte dal fatto che le applicazioni che si desidera distribuire in Azure richiedano o meno l'accesso alle risorse nella rete locale.

Se le applicazioni soddisfano i criteri riportati di seguito, possono essere distribuite isolate dalla rete locale.

  • In esse vengono accettati i token di sicurezza SAML

  • Possono essere esposte in Internet

  • Tramite esse non si accede alle risorse locali

In questo caso, configurare i ruoli STS ADFS di Windows Server come riportato di seguito:

  1. Configurare una foresta a dominio singolo isolata in Azure.

  2. Fornire accesso federato alla foresta configurando una server farm federativa ADFS di Windows Server.

  3. Configurare ADFS di Windows Server (server farm federativa e farm proxy server federativo) nella foresta locale.

  4. Stabilire una relazione di trust federativa tra le istanze di Azure e locali di ADFS di Windows Server.

D'altra parte, se tramite le applicazioni è necessario accedere alle risorse locali, è possibile configurare ADFS di Windows Server con l'applicazione in Azure come riportato di seguito:

  1. Configurare la connettività tra le reti locali e Azure.

  2. Configurare una server farm federativa ADFS di Windows Server nella foresta locale.

  3. Configurare una farm proxy server federativo ADFS di Windows Server in Azure.

Questa configurazione offre il vantaggio di poter ridurre l'esposizione delle risorse locali, analogamente alla configurazione di ADFS di Windows Server con applicazioni in una rete perimetrale.

Si noti che in entrambi gli scenari è possibile stabilire relazioni di trust con più provider di identità, se è necessaria la collaborazione business-to-business.

I servizi cloud sono necessari se si desidera esporre una VM direttamente in Internet o un'applicazione con bilanciamento del carico con connessione Internet. Ciò è possibile perché ogni servizio cloud offre un VIP singolo configurabile.

A ogni macchina virtuale di Azure viene associato un DIP. Un DIP è un indirizzo privato accessibile solo in Azure. Nella maggior parte dei casi, tuttavia, sarà necessario configurare un VIP per le distribuzioni di ADFS di Windows Server. Il VIP è necessario per esporre endpoint ADFS di Windows Server in Internet che saranno usati da partner e client federativi per l'autenticazione e la gestione in corso. Un VIP è una proprietà di un servizio cloud in cui sono contenute una o più macchine virtuali di Azure. Se l'applicazione in grado di riconoscere attestazioni distribuita in Azure e ADFS di Windows Server sono entrambi con connessione Internet e condividono porte comuni, per ognuno sarà necessario un proprio VIP e sarà pertanto necessario creare un servizio cloud per l'applicazione e un altro per ADFS di Windows Server.

Per le definizioni dei termini VIP e DIP, vedere Termini e definizioni.

Sebbene sia possibile distribuire servizi federativi ADFS di Windows Server autonomi, è consigliabile distribuire una farm con almeno due nodi sia per i ruoli STS ADFS sia per i proxy per gli ambienti di produzione.

Per stabilire le opzioni di configurazione per la distribuzione che meglio soddisfano le proprie particolari esigenze, vedere la pagina relativa alle considerazioni sulla topologia di distribuzione di ADFS 2.0 nella guida alla progettazione di ADFS 2.0.

noteNota
Per ottenere il bilanciamento del carico per gli endpoint ADFS di Windows Server in Azure, configurare tutti i membri della farm di ADFS di Windows Server nello stesso servizio cloud e usare la funzionalità di bilanciamento del carico di Azure per le porte HTTP (80 per impostazione predefinita) e HTTPS (443 per impostazione predefinita). Per altre informazioni, vedere il probe di bilanciamento del carico di Azure.

Il bilanciamento del carico di rete di Windows Server non è supportato in Azure.

Mostra:
© 2014 Microsoft