VENDITE: 1-800-867-1389

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

Aggiornamento: aprile 2014

In questo documento vengono illustrate le differenze principali tra la distribuzione in locale e la distribuzione in macchine virtuali di 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/Rete virtuale di Microsoft Azure e le distribuzioni tradizionali di Active Directory in locale. Macchine virtuali di Microsoft Azure e Rete virtuale di Microsoft Azure fanno parte di una soluzione IaaS (Infrastructure-as-a-Service, Infrastruttura come servizio) che offre alle organizzazioni la possibilità di utilizzare 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 la pagina relativa alla guida alla distribuzione di ADFS 2.0 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) tramite cui è possibile utilizzare 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 Servizi di dominio Active Directory o ADFS 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 nelle 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.

Nel documento non vengono illustrate né la distribuzione né la configurazione di Microsoft Azure Active Directory, un servizio basato su REST che fornisce funzionalità di gestione dell'identità e controllo di accesso per le applicazioni cloud. Microsoft Azure AD 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 moderne applicazioni e per gli ambienti IT ibridi attuali. Per comprendere le differenze e le relazioni tra Servizi di dominio Active Directory di Windows Server e Microsoft Azure AD, si tenga presente quanto riportato di seguito:

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

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

  3. È possibile utilizzare il servizio di controllo di accesso di Microsoft Azure Active Directory 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 ulteriori informazioni su queste differenze, vedere la pagina relativa all'identità di Azure.

Esistono differenze minime tra i requisiti essenziali per la distribuzione di Active Directory di Windows Server in macchine virtuali di Azure e in macchine virtuali (e, in una certa misura, macchine fisiche) in locale. 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 può essere sostanzialmente gestita nello stesso modo in 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 utilizzando collegamenti di sito appropriati. Vi sono, tuttavia, alcune differenze che sono comuni a tutte le distribuzioni di Azure e altre che variano in base allo scenario specifico di distribuzione. Di seguito sono descritte tre differenze fondamentali che verranno illustrate in modo più dettagliato nei paragrafi seguenti:

  1. Può essere necessario connettere le macchine virtuali di Azure alla rete aziendale locale.

    Per la riconnessione di macchine virtuali di Azure a una rete aziendale locale è necessaria una 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 facilmente 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 utilizzando 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 l'esercitazione relativa alla creazione di una rete virtuale con connettività tra più sedi locali, vedere la pagina relativa alla rete.

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

  2. Gli indirizzi IP statici sono supportati nelle macchine virtuali di Azure, ma è necessario configurarli utilizzando Azure PowerShell.

    Gli indirizzi dinamici sono allocati per impostazione predefinita. Per gli indirizzi dinamici è richiesta la creazione di una rete virtuale di Azure. Gli indirizzi IP dinamici delle macchine virtuali di Azure associati a una rete virtuale di Azure sono validi per la durata della macchina virtuale. In questo modo vengono soddisfatti i requisiti di Active Directory di Windows Server e di DNS per l'impostazione degli indirizzi IP.

    Tuttavia, quando una macchina virtuale viene arrestata, l'indirizzo IP dinamico viene deallocato. Per evitare che l'indirizzo IP venga deallocato, è possibile utilizzare il cmdlet Set-AzureStaticVNetIP per assegnare un indirizzo IP statico.

    Per ulteriori informazioni, vedere Impostazione indirizzi IP e DNS.

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. Per un glossario completo, vedere la pagina relativa al glossario di Azure.

  • Macchine virtuali di Microsoft 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 Microsoft 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. Un VIP viene assegnato ai servizi cloud per ricevere il traffico di rete che viene reindirizzato a una VM di Microsoft Azure. Un indirizzo VIP è una proprietà di un servizio cloud in cui possono essere contenute una o più macchine virtuali di Azure. Inoltre, si noti 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): indirizzo IP assegnato dinamicamente all'adattatore di rete virtuale di una macchina virtuale di Azure tramite DHCP. L'indirizzo IP, tuttavia, verrà reso persistente in questa macchina virtuale per l'intera durata della distribuzione nello stesso modo in cui le prenotazioni DHCP vengono collegate ai singoli indirizzi MAC.

  • 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 dell'adattatore di rete virtuale non verrà modificata finché la VM è collegata a una rete virtuale e la configurazione IP della VM viene definita come parte della rete virtuale o della VM stessa (non del sistema operativo guest)

    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, per garantire la persistenza dell'indirizzo IP tramite la correzione del servizio.

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 ulteriori 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 utilizzare 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. Anche se Azure non fornisce funzionalità di ripristino di snapshot, 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'utilizzo 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 ulteriori informazioni sull'impatto sui controller di dominio, vedere la pagina relativa a USN e rollback di USN.

A partire da Windows Server 2012, Servizi di dominio Active Directory offre misure di sicurezza aggiuntive destinate a proteggere i controller di dominio virtualizzati dai suddetti problemi, purché la piattaforma Hypervisor sottostante supporti VM-GenerationID. Azure supporta VM-GenerationID, pertanto i controller di dominio che eseguono Windows Server 2012 o versioni successive nelle macchine virtuali di Azure dispongono di misure di sicurezza aggiuntive. Per ulteriori informazioni, vedere Introduzione alla virtualizzazione di Servizi di dominio Active Directory.

Molti scenari di distribuzione di Servizi di dominio Active Directory di Windows Server sono ideali per la distribuzione come 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 che dovrà essere eseguita nel data center di Microsoft 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, tramite il componente VPN, che offre connettività tra una rete virtuale di Azure e una rete locale, è inoltre possibile abilitare server membri in esecuzione in locale per l'utilizzo di controller di dominio eseguiti come macchine virtuali di Azure in Rete virtuale di Microsoft Azure. Tuttavia, se il componente VPN non è disponibile, le comunicazioni tra i computer locali e i controller di dominio basati su Azure non funzioneranno, con conseguenti errori di autenticazione e di altra natura.  

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

    La coerenza di indirizzi IP nella rete virtuale di Azure si ottiene utilizzando un terzo nuovo tipo concettuale di indirizzo IP che è simile alle prenotazioni DHCP. Attualmente, gli indirizzi IP statici vengono assegnati all'interno del sistema operativo a una scheda di interfaccia di rete specifica. Gli indirizzi dinamici vengono assegnati automaticamente in lease dai server DHCP in base agli ambiti definiti nel server DHCP.

    Dalle reti virtuali di Azure è stato introdotto un terzo tipo concettuale di indirizzo che differisce solo leggermente dall'allocazione di indirizzi DHCP. Con le macchine virtuali di Azure, per impostazione predefinita la macchina virtuale è configurata per il lease di un indirizzo IP da DHCP. A differenza degli indirizzi dinamici tipici, tuttavia, che possono essere modificati alla scadenza di un lease, gli indirizzi dinamici nelle reti virtuali di Azure vengono garantiti per la durata della macchina virtuale nello stesso modo in cui funzionano le prenotazioni DHCP, finché la VM non viene arrestata.

    Se la macchina virtuale viene arrestata, l'indirizzo IP viene deallocato e può essere assegnato un indirizzo IP diverso al riavvio della VM. Per evitare che l'indirizzo IP venga deallocato, in caso di arresto è possibile assegnare un indirizzo IP statico utilizzando il cmdlet Set-AzureStaticVNetIP. Per ulteriori informazioni su come utilizzare Set-AzureStaticVNetIP, vedere la pagina relativa alla configurazione di un indirizzo IP interno statico (DIP) per una VM e la pagina relativa alla modalità di assegnazione di un IP statico privato a una VM di Microsoft Azure.

    ImportantImportante
    La configurazione di un indirizzo IP statico nella VM determinerà alla fine la perdita completa di connettività a questa macchina.

  • 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 ulteriori informazioni, vedere Panoramica di Rete virtuale e Tutorial 2: Creating a Virtual Network for cross-premises connectivity.

    noteNota
    Un'opzione per configurare una VPN da punto a sito è disponibile per connettere direttamente singoli computer basati su Windows 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. Per ulteriori informazioni sugli addebiti di traffico, vedere Panoramica dei prezzi di Azure.

  • È importante notare che non vi è connettività diretta tra reti virtuali di Azure separate. In altre parole, se si creano due reti virtuali, ad esempio geograficamente distribuite, le comunicazioni tra le VM di Microsoft Azure collegate a queste reti sono possibili solo connettendo le due reti virtuali alla stessa rete aziendale tramite la funzionalità VPN da sito a sito. Le comunicazioni tra le due reti virtuali sono quindi possibili, ma solo indirizzando il traffico tramite la rete aziendale. Pertanto, per le comunicazioni tra controller di dominio geograficamente distribuiti in reti virtuali separate è necessario attraversare sia le reti virtuali sia la rete aziendale. Ad esempio, in caso di comunicazioni tra una VM di Microsoft Azure presente in una rete virtuale in Asia e un'altra che si trova in Sud America, le comunicazioni end-to-end devono attraversare la rete interna.

  • Sebbene si disponga di un controllo completo sulle risorse server da utilizzare per le VM locali in Azure, ad esempio la quantità di RAM, le dimensioni del disco e così via, è 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. Per ulteriori informazioni sulle risorse di elaborazione disponibili, vedere 7 informazioni importanti sulla capacità di Windows Azure.

ADFS è supportato per la distribuzione in macchine virtuali di Azure, tuttavia alcune delle procedure consigliate di ADFS richiedono tecnologie più avanzate rispetto a quelle offerte da ADFS, come il bilanciamento del carico e la disponibilità elevata. Dal momento che queste tecnologie non fanno parte del set di funzionalità native di ADFS, è necessario che vengano fornite dall'infrastruttura sottostante. È ad esempio consigliabile che i ruoli STS (Servizio token di sicurezza) e proxy di ADFS siano caratterizzati da disponibilità elevata e carico bilanciato. Azure non è in grado di soddisfare questi requisiti di bilanciamento del carico e disponibilità elevata nelle interfacce private (DIP) di una macchina virtuale, pertanto è necessario un compromesso per alcune configurazioni di distribuzione ADFS.

Una possibile configurazione di distribuzione tramite ADFS che soddisfa tutte le procedure consigliate e non richiede compromessi prevede il semplice spostamento dei proxy ADFS dalla rete perimetrale locale ad Azure. La configurazione si basa sulle funzionalità di bilanciamento del carico di Azure per i VIP, che soddisfa completamente le procedure consigliate per il bilanciamento del carico e la disponibilità elevata per l'esecuzione di ADFS. Per ulteriori informazioni su questo scenario, vedere 2. ADFS: estendere in Internet un'applicazione front-end locale in grado di riconoscere attestazioni.

Per comprendere meglio le possibili configurazioni di distribuzione di ADFS in cui è necessario questo compromesso, considerare il seguente aggiornamento in merito al modo in cui ADFS viene in genere distribuito in locale, quindi raffrontarlo con le opzioni attualmente a disposizione utilizzando le macchine virtuali di Azure. Nella diagramma indicato di seguito, disponibile nell'articolo Pianificare la distribuzione di ADFS, viene illustrata una tipica distribuzione di ADFS.

Database interno di Windows per AD FS e proxy

I ruoli STS vengono distribuiti all'interno del firewall aziendale e utilizzano il bilanciamento del carico di rete per il bilanciamento del carico. Se un utente associato alla rete aziendale e connesso al dominio corp.fabrikam.com richiede l'accesso a Office 365 in questo scenario, viene reindirizzato all'endpoint con carico bilanciato/altamente disponibile davanti ai ruoli STS.

I proxy ADFS vengono distribuiti nelle reti perimetrali e utilizzano il bilanciamento del carico di rete per bilanciare il carico delle richieste degli utenti esterni. Le richieste esterne vengono infine passate dai proxy ADFS all'endpoint con carico bilanciato/altamente disponibile davanti ai ruoli STS.

In tutti i casi, si noti che questa procedura consigliata assicura che le interfacce utilizzate siano caratterizzate da carico bilanciato e disponibilità elevata. Il modo in cui viene raggiunto questo risultato non è importante e il bilanciamento del carico di rete viene utilizzato come un possibile esempio.

noteNota
Per ulteriori informazioni sulla procedura di autenticazione dell'utente in questo scenario, vedere Funzionamento di ADFS con Office 365

Nella maggior parte dei casi, l'errore di un'applicazione abilitata da ADFS non è accettabile perché queste applicazioni sono spesso mission-critical. Di conseguenza e poiché ADFS ora risiede nel percorso critico per l'accesso alle applicazioni, è consigliabile attenersi alle procedure consigliate seguenti, come illustrato nel diagramma precedente:

  1. Non esporre mai i servizi token di sicurezza direttamente su Internet.

    Come procedura di sicurezza consigliata, posizionare le istanze STS dietro a un firewall e connetterle alla rete aziendale per impedire l'esposizione a Internet. Questo è importante poiché il ruolo STS rilascia token di sicurezza. Di conseguenza, devono disporre dello stesso livello di protezione di un controller di dominio. Se un servizio token di sicurezza (STS) viene compromesso, gli utenti malintenzionati hanno la possibilità di rilasciare token di accesso contenenti attestazioni alle applicazioni relying party e ad altri servizi token di sicurezza nelle organizzazioni attendibili.

  2. Il servizio ADFS deve essere a disponibilità elevata.

    Se l'applicazione che richiede ADFS è mission-critical, il servizio ADFS deve essere caratterizzato da disponibilità elevata per mantenere l'accesso all'applicazione. Per garantire la disponibilità elevata, i servizi di bilanciamento del carico vengono in genere distribuiti davanti ai proxy ADFS e ai ruoli STS.

Considerare ora in che modo è possibile distribuire questa configurazione nelle macchine virtuali di Azure. Il segno di spunta verde indica che è possibile soddisfare il requisito delle procedure consigliate senza alcun compromesso, mentre il simbolo X rosso indica che il requisito non può essere soddisfatto mediante macchine virtuali di Azure.

AD FS e proxy in Windows Azure

Si noti che il bilanciamento del carico e la disponibilità elevata non possono essere forniti per i ruoli STS. L'unico modo per eseguire il bilanciamento del carico dei ruoli STS consisterebbe nell'esporli utilizzando un indirizzo VIP perché questi indirizzi offrono funzionalità di bilanciamento del carico native, mentre i DIP non forniscono alcuna funzionalità di bilanciamento del carico. In questo modo, tuttavia, si viola la procedura consigliata n.1 (non esporre mai i ruoli STS direttamente a Internet).

In breve, la soluzione implica un compromesso a livello di disponibilità elevata o di sicurezza. Nessuno di questi compromessi è in genere accettabile se l'applicazione è mission-critical poiché ADFS risiede nel percorso critico per accedere all'applicazione.

Possibilità di distribuire i ruoli STS utilizzando un indirizzo VIP e configurando un firewall

Sebbene possa essere possibile porre vincoli del firewall sull'indirizzo VIP, è necessario razionalizzare il requisito di manutenzione, configurazione e stabilità a lungo termine rispetto al valore fornito. Considerare le regole che sarebbe necessario aggiungere o come esprimere una regola firewall VIP che consenta l'accesso all'endpoint VIP con carico bilanciato dai proxy e dagli utenti locali. Considerare inoltre la logistica per mantenere l'elenco ACL poiché i provider di rete aziendali cambiano nel tempo e, ancora più importante, la perdita risultante dell'accesso all'applicazione. È inoltre possibile soddisfare il requisito di bilanciamento del carico distribuendo la tecnologia di bilanciamento del carico in locale, quindi davanti ai ruoli STS che risiedono in Azure. Così facendo, tuttavia, si crea una soluzione molto complicata e una proposta di risoluzione dei problemi complessa qualora si verificassero degli errori. Questo entra in contrasto con uno dei motivi fondamentali che inducono a passare a Azure, ovvero semplificazione, riduzione dei costi e così via.

Un'alternativa se l'obiettivo è solo Office 365

Se l'obiettivo è solo Office 365, è sufficiente distribuire DirSync con la sincronizzazione password in locale e ottenere lo stesso risultato finale con una complessità di distribuzione quasi nulla. Nota: 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 utilizzando ADFS e DirSync Stesso punto di accesso singolo a Office 365 utilizzando 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 a Microsoft Azure AD.

  4. Poiché Microsoft Azure AD non è in grado di autenticare l'utente e rileva l'esistenza di una relazione di trust con ADFS in locale, l'utente viene reindirizzato ad 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 Microsoft Azure AD.

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

  8. Microsoft Azure AD 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 a Microsoft Azure AD.

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

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

  6. Microsoft Azure AD reindirizza l'utente a Office 365.

  7. L'utente può accedere a Office 365 e OWA utilizzando il token di Microsoft Azure AD.

In questo scenario di sincronizzazione della password + DirSync (ADFS non coinvolto), single-sign-on viene sostituito da "same-sign-on" dove "same" indica semplicemente che gli utenti devono immettere nuovamente le stesse credenziali locali per l'accesso a Office 365. Si noti che questi dati possono essere memorizzati per ridurre le richieste successive.

Conclusione

La distribuzione di ADFS in macchine virtuali di Azure è una questione di rapporto rischi-benefici. I benefici ottenuti dalla distribuzione di ADFS in Azure potrebbero essere maggiori dei rischi, ma questa è una decisione che deve essere presa nel contesto dello scenario di distribuzione. Nella tabella riportata di seguito si tenta di acquisire la matrice della decisione.

 

Distribuzione Benefici Rischi

Distribuzione dei ruoli STS utilizzando solo il relativo DIP

Distribuzione sicura conforme alle procedure consigliate

Disponibilità elevata e bilanciamento del carico compromessi

Distribuzione dei ruoli STS utilizzando un indirizzo VIP

Disponibilità elevata e bilanciamento del carico

Procedure consigliate legittime relative alla sicurezza ignorate

Distribuzione dei ruoli STS utilizzando un indirizzo VIP più regole firewall

Sicurezza e disponibilità elevata

Semplicità compromessa e configurazione fragile

Distribuzione dei servizi di bilanciamento del carico locali davanti ai ruoli STS che utilizzano solo DIP in Azure

Sicurezza e disponibilità elevata

Semplicità della risoluzione dei problemi compromessa

Ulteriori riflessioni

  • Se si distribuisce un proxy ADFS di Windows Server in una macchina virtuale di Azure, è necessario disporre di connettività ai ruoli STS di ADFS. Se si tratta di ruoli locali, è consigliabile utilizzare la connettività VPN da sito a sito fornita dalla rete virtuale per consentire ai proxy di comunicare con i relativi ruoli STS.

  • Se si distribuisce un servizio token di sicurezza di ADFS di Windows Server in una macchina virtuale di Azure, è necessario disporre della connettività ai controller di dominio Active Directory di Windows Server, agli archivi di attributi e ai database di configurazione e di una VPN da sito a sito.

  • Gli addebiti vengono applicati a tutto il traffico in uscita delle macchine virtuali di Azure. Se il costo è un fattore determinante, è consigliabile distribuire i proxy ADFS in Azure, lasciando i ruoli STS in locale. Se i ruoli STS 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 attraversi o meno la VPN.

  • Se si decide di utilizzare le funzionalità di bilanciamento del carico del server native di Azure per la disponibilità elevata dei ruoli STS di ADFS, si noti che il servizio di bilanciamento del carico offre probe per determinare l'integrità delle macchine virtuali all'interno del servizio cloud. Nel caso di macchine virtuali di Azure (anziché dei ruoli Web o di lavoro), è necessario utilizzare un probe personalizzato poiché l'agente tramite cui si risponde ai probe predefiniti non è presente nelle macchine virtuali di Azure. Per motivi di semplicità, è possibile utilizzare un probe TCP personalizzato, per il quale occorre solo una corretta connessione TCP (SYN ACK) per determinare l'integrità della macchina virtuale. È possibile configurare il probe personalizzato per utilizzare qualsiasi porta TCP attivamente in ascolto sulle macchine virtuali. A tale scopo, vedere la pagina relativa al probe di bilanciamento del carico di Azure.

    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: utilizzare il sito Active Directory di Windows Server predefinito (il valore predefinito di tutti i computer sarà Nome-predefinito-primo-sito)

  • Impostazione indirizzi IP e DNS:

    • Utilizzare gli indirizzi con lease DHCP o, se si intende arrestare la VM e si desidera mantenere un indirizzo con lease DHCP, utilizzare il cmdlet Set-AzureStaticVNetIP di Azure PowerShell.

    • 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 VM che ospita i ruoli server DNS e del controller di dominio.

  • 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 VM di Microsoft 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 utilizzata dagli utenti aziendali deve essere accessibile direttamente da Internet. L'applicazione viene utilizzata come front-end Web in un database SQL in cui vengono archiviati e recuperati i dati. I server SQL utilizzati 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 utilizzare 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 fornire due VIP con bilanciamento del carico. Il VIP del primo servizio cloud verrà indirizzato alle due VM del proxy ADFS di Windows Server sulle porte 80 e 443. Tali VM verranno configurate in modo che facciano riferimento all'indirizzo IP del servizio di bilanciamento del carico locale che utilizza i ruoli STS di ADFS di Windows Server. Il VIP del secondo servizio cloud verrà indirizzato alle due VM in cui viene eseguito il front-end Web, anche in questo caso sulle porte 80 e 443. Configurare un probe personalizzato per assicurarsi che il traffico del bilanciamento del carico venga indirizzato solo al proxy ADFS di Windows Server e alle VM front-end Web funzionanti.

  • Configurazione del server federativo: configurare ADFS di Windows Server come server federativo (STS) 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 ADFS di Windows Server con almeno due server per il failover e il bilanciamento del carico. Si valuti la possibilità di utilizzare Database interno di Windows per i dati di configurazione di ADFS di Windows Server e utilizzare la funzionalità nativa di bilanciamento del carico del server di Azure per distribuire le richieste in entrata nei server della farm. Il servizio di bilanciamento del carico nativo di Azure è supportato solo quando si utilizza un indirizzo VIP rivolto a Internet. I DIP non possono essere sottoposti a bilanciamento del carico.

    Per ulteriori informazioni, vedere la pagina relativa alla guida alla distribuzione di ADFS 2.0.

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 utilizzato come repository 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. Per questa operazione sarà necessario distribuire un endpoint VPN compatibile nel perimetro della rete aziendale. Per ulteriori informazioni, vedere l'articolo relativo ai dispositivi VPN per la rete virtuale.

  • 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, utilizzare 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 Install a replica Active Directory DC in Windows Azure Virtual Network. Anche se si utilizza 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 includa 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:

    • Utilizzare gli indirizzi con lease DHCP o, se si intende arrestare la VM e si desidera mantenere un indirizzo con lease DHCP, utilizzare il cmdlet Set-AzureStaticVNetIP di Azure PowerShell.

    • 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 VM che ospita i ruoli server DNS e del controller di dominio.

  • Controller di dominio geograficamente distribuiti: configurare reti virtuali aggiuntive in base alle esigenze. Se è richiesta la comunicazione diretta tra le reti virtuali, entrambe devono essere configurate per l'utilizzo delle funzionalità VPN da sito a sito e tutto il traffico tra esse verrà indirizzato tramite la rete aziendale interna.

  • 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 ulteriori 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 a 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 memorizzazione nella cache dell'appartenenza a gruppi 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 nelle VM di Microsoft 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 Microsoft 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?

Utilizzare solo indirizzi con lease DHCP di Azure

Installare il server DNS di Windows Server

5

Controller di dominio geograficamente distribuiti

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

Nessuna comunicazione diretta tra reti virtuali geograficamente separate

6

Controller di dominio di sola lettura

Utilizzare 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?

ImportantImportante
Non utilizzare SYSPREP per clonare i controller di dominio. È tuttavia possibile utilizzare la clonazione di un controller di dominio virtuale con macchine virtuali di Azure in cui viene eseguito Windows Server 2012.

  • 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 Microsoft Azure anziché nei dischi del sistema operativo tramite cui viene implementata la memorizzazione nella cache di scrittura.

10

Backup e ripristino

Come proteggere e recuperare i dati?

Creare backup dello stato del sistema

Non copiare né clonare i file VHD

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 una 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 utilizzate 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 ulteriori informazioni sugli addebiti del 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 ulteriori informazioni sugli addebiti del 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 utilizzare 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 un 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 utilizzato 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 Microsoft 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 utilizzano 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 un sito 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 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 ulteriori 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 stessa, i requisiti di Servizi di dominio Active Directory di Windows Server vengono soddisfatti.

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

Tuttavia, quando una macchina virtuale viene arrestata, l'indirizzo IP dinamico viene deallocato. Per evitare che l'indirizzo IP venga deallocato, è possibile utilizzare il cmdlet Set-AzureStaticVNetIP per assegnare un indirizzo IP statico.

Per la risoluzione dei nomi, distribuire la propria infrastruttura del server DNS (o utilizzare 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 legati alle prestazioni e alla 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 di Azure con il nome e l'indirizzo IP del server DNS. In questo modo, all'avvio di altre VM nella rete virtuale, vengono configurate le relative impostazioni del sistema di risoluzione client DNS con il server DNS come parte dell'allocazione dinamica di indirizzi IP.

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 ulteriori informazioni su questo caso e su un altro esempio in cui viene illustrato il provisioning della prima VM e l'installazione in quest'ultima di Servizi di dominio Active Directory, vedere la pagina relativa all'installazione di una nuova foresta Active Directory in Azure. Per ulteriori informazioni sull'utilizzo di Windows PowerShell, vedere l'introduzione ad Azure PowerShell e ai cmdlet di gestione di Azure.

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

  • Tolleranza di errore multisito

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

Tuttavia, non esiste alcuna comunicazione diretta tra le reti virtuali di Azure. Tutte le comunicazioni tra le diverse reti virtuali di Azure devono essere indirizzate attraverso la rete locale e ciò può comportare grandi quantità di traffico in uscita e conseguenti costi elevati.

Nessuna connettività tra reti virtuali

Figura 4

È 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 utilizzare 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 ulteriori 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 utilizzare. 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 ulteriori 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 ciascun 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:

Utilizzare solo Macchine virtuali di Microsoft Azure per i controller di dominio, anziché VM 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, come i controller di dominio.

Non utilizzare 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. Sia Hyper-V in Windows Server 2012 sia Reti virtuali di Microsoft Azure supportano 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. È necessario distribuirli nei dischi dati di Azure. “

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

Nelle unità disco dati le scritture non vengono memorizzate nella cache per impostazione predefinita. Nelle unità disco dati associate a una VM viene utilizzata la funzionalità cache write-through. La funzionalità cache write-through assicura il commit della scrittura nell'archiviazione di Microsoft Azure durevole prima del completamento della transazione dal punto di vista del sistema operativo della VM. 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.

Come procedura consigliata per i controller di dominio virtuali, eseguire le operazioni seguenti:

  • Impostare l'opzione Preferenze cache dell'host nel disco dati di Azure su NESSUNO. In questo modo si eviteranno 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 utilizzato per il sistema operativo stesso. L'informazione chiave è 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 di 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 utilizzando 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 utilizzando 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 quelle 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 assegnato 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 utilizzati 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 le distribuzioni dell'applicazione in grado di riconoscere attestazioni in Azure e in ADFS di Windows Server sono entrambe con connessione Internet e condividono porte comuni, ognuna richiederà un proprio VIP e sarà pertanto necessario creare un servizio cloud per l'applicazione e uno 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 utilizzare la funzionalità di bilanciamento del carico di Azure per le porte HTTP (80 per impostazione predefinita) e HTTPS (443 per impostazione predefinita). Per ulteriori informazioni, vedere il probe di bilanciamento del carico di Azure.

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

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2014 Microsoft