Estensione di AD FS locali in Azure

Questa architettura di riferimento implementa una rete ibrida protetta che consente di estendere la rete locale in Azure e usa Active Directory Federation Services (ADFS) per eseguire l'autorizzazione e l'autenticazione federate per i componenti in esecuzione in Azure.

Architettura

Scaricare un file di Visio di questa architettura.

Flusso di lavoro

• Subnet di Active Directory Domain Services. I server Active Directory Domain Services sono inclusi nella propria subnet con regole NSG (network security group) che fungono da firewall.

• Server Active Directory Domain Services. Controller di dominio in esecuzione come macchine virtuali in Azure. Questi server forniscono l'autenticazione delle identità locali all'interno del dominio.

• Subnet di AD FS. I server AD FS si trovano all'interno della propria subnet con regole NSG che fungono da firewall.

• Server AD FS. I server AD FS forniscono autenticazione e autorizzazione federate. In questa architettura eseguono le attività seguenti:

  • Ricevono i token di sicurezza contenenti attestazioni eseguite da un server federativo partner per conto di un utente partner. AD FS verifica che i token siano validi prima di passare le attestazioni all'applicazione Web in esecuzione in Azure per autorizzare le richieste.

    L'applicazione in esecuzione in Azure è la relying party. Il server federativo partner deve rilasciare attestazioni riconosciute dall'applicazione Web. I server federativi partner sono detti partner account, perché inviano richieste di accesso per conto di account autenticati nell'organizzazione partner. Il server AD FS sono denominati partner risorse, in quanto forniscono l'accesso alle risorse (l'applicazione Web).

  • Autenticano e autorizzano le richieste in entrata degli utenti esterni che eseguono un Web browser o un dispositivo che richiede l'accesso alle applicazioni Web usando Active Directory Domain Services e AD Device Registration Service.

  I server AD FS sono configurati come una farm a cui si accede tramite un servizio di bilanciamento del carico di Azure. Questa implementazione migliora la disponibilità e la scalabilità. I server AD FS non sono esposti direttamente a Internet. Tutto il traffico Internet viene filtrato attraverso i server proxy delle applicazioni Web AD FS e una DMZ (definita anche rete perimetrale).

  Per altre informazioni sul funzionamento di AD FS, vedere la panoramica su Active Directory Federation Services. Inoltre, l'articolo Distribuzione di Active Directory Federation Services in Azure contiene un'introduzione dettagliata all'implementazione.

• Subnet proxy di AD FS. I server proxy AD FS possono essere inclusi nelle proprie subnet, con regole NSG che ne garantiscono la protezione. I server di questa subnet sono esposti a Internet tramite un set di dispositivi virtuali di rete che forniscono un firewall tra la rete virtuale di Azure e Internet.

• Server WAP (web application proxy) AD FS. Queste macchine virtuali fungono da server AD FS per le richieste in ingresso di organizzazioni partner e dispositivi esterni. I server WAP fungono da filtro, proteggendo i server AD FS dall'accesso diretto da Internet. Come accade con i server AD FS, la distribuzione dei server WAP in una farm con il bilanciamento del carico garantisce maggiore disponibilità e scalabilità rispetto alla distribuzione di una raccolta di server autonomi.

  Nota

  Per informazioni dettagliate sull'installazione dei server WAP, vedere Installare e configurare il server del proxy dell'applicazione Web

• Organizzazione partner. Un'organizzazione partner che esegue un'applicazione Web che richiede l'accesso a un'applicazione Web in esecuzione in Azure. Il server federativo nell'organizzazione partner autentica le richieste in locale e invia i token di sicurezza contenenti le attestazioni ad AD FS in esecuzione in Azure. AD FS in Azure convalida i token di sicurezza e, se sono validi, può trasferire le attestazioni all'applicazione Web in esecuzione in Azure per autorizzarle.

  Nota

  È inoltre possibile configurare un tunnel VPN tramite il gateway di Azure per consentire ai partner attendibili l'accesso diretto ad AD FS. Le richieste ricevute da tali partner non passano attraverso i server WAP.

Componenti

Questa architettura estende l'implementazione descritta nell'articolo relativo all'estensione di Active Directory Domain Services (AD DS) in Azure. Contiene i componenti seguenti.

• Subnet di Active Directory Domain Services
• Server di Active Directory Domain Services
• Subnet AD FS
• AD FS servers
• Subnet proxy AD FS
• Server proxy applicazione Web AD FS (WAP)

Dettagli dello scenario

AD FS può essere ospitato in locale, ma se l'applicazione è un ambiente ibrido in cui alcune parti vengono implementate in Azure, potrebbe essere più efficiente replicare AD FS nel cloud.

Il diagramma precedente illustra gli scenari seguenti:

• Il codice dell'applicazione di un'organizzazione partner accede a un'applicazione Web ospitata all'interno della rete virtuale di Azure.
• Un utente esterno registrato con le credenziali archiviate all'interno di Active Directory Domain Services (AD DS) accede a un'applicazione Web ospitata nella rete virtuale di Azure.
• Un utente connesso alla rete virtuale con un dispositivo autorizzato esegue un'applicazione Web ospitata nella rete virtuale di Azure.

Questa architettura di riferimento è incentrata sulla federazione passiva, in cui i server federativi decidono come e quando autenticare un utente. L'utente fornisce informazioni di accesso quando l'applicazione viene avviata. Questo meccanismo viene usato più comunemente dai Web browser e prevede un protocollo che reindirizza il browser a un sito in cui l'utente viene autenticato. AD FS supporta anche la federazione attiva, in cui un'applicazione si assume la responsabilità di fornire le credenziali senza ulteriore intervento dell'utente, ma questo scenario non rientra nell'ambito di questa architettura.

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

Potenziali casi d'uso

Tra gli usi tipici di questa architettura sono inclusi:

• Applicazioni ibride in cui i carichi di lavoro vengono eseguiti in parte in locale e in parte in Azure.
• Soluzioni che usano l'autorizzazione federata per esporre le applicazioni Web per le organizzazioni partner.
• Sistemi che supportano l'accesso da Web browser in esecuzione all'esterno del firewall aziendale.
• Sistemi che consentono agli utenti di accedere alle applicazioni Web tramite la connessione da dispositivi esterni autorizzati, ad esempio computer remoti, notebook e altri dispositivi mobili.

Consigli

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

Raccomandazioni di rete

Configurare l'interfaccia di rete per tutte le macchine virtuali che ospitano i server AD FS e WAP con indirizzi IP privati statici.

Non assegnare agli indirizzi IP pubblici delle macchine virtuali AD FS. Per altre informazioni, vedere la sezione Considerazioni relative alla sicurezza.

Impostare l'indirizzo IP dei server DNS (domain name service) preferito e secondario per le interfacce di rete per ogni macchina virtuale AD FS e WAP che faccia riferimento alle macchine virtuali Active Directory DS. Sulle macchine virtuali Active Directory DS deve essere in esecuzione DNS. Questo passaggio è necessario per consentire di aggiunger ogni macchina virtuale al dominio.

Installazione di AD FS

L'articolo Distribuzione di Active Directory Federation Services in Azure fornisce istruzioni dettagliate per l'installazione e la configurazione di AD FS. Prima di configurare il primo server AD FS nella farm, eseguire le attività seguenti:

1. Ottenere un certificato attendibile pubblicamente per eseguire l'autenticazione server. Il nome soggetto deve contenere il nome usato dai client per accedere al servizio federativo. Può trattarsi del nome DNS registrato per il bilanciamento del carico, ad esempio adfs.contoso.com (per motivi di sicurezza, evitare di usare nomi con caratteri jolly, come *.contoso.com). Usare lo stesso certificato in tutte le macchine virtuali del server AD FS. È possibile acquistare un certificato da un'autorità di certificazione attendibile ma, se l'organizzazione usa Servizi certificati Active Directory, è possibile crearne uno personalizzato.

   Il nome alternativo del soggetto viene usato dal servizio Registrazione dispositivi (DRS) per consentire l'accesso dai dispositivi esterni. Deve essere nel formato enterpriseregistration.contoso.com.

   Per altre informazioni, vedere Ottenere e configurare un certificato SSL (Secure Sockets Layer) per AD FS.

2. Nel controller di dominio generare una nuova chiave radice per il servizio di distribuzione chiavi. Impostare il periodo di validità sull'ora corrente meno 10 ore (questa configurazione riduce il ritardo che può verificarsi durante la distribuzione e la sincronizzazione delle chiavi all'interno del dominio). Questo passaggio è necessario per supportare la creazione dell'account del servizio di gruppo usato per eseguire il servizio AD FS. Il comando PowerShell seguente illustra un esempio di come eseguire questa operazione:

   Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
   

3. Aggiungere ogni macchina virtuale del server AD FS al dominio.

Trust AD FS

Stabilire una relazione di trust federativa tra l'installazione di AD FS e i server federativi di tutte le organizzazioni partner. Configurare i filtri e il mapping di attestazioni richiesti.

• Il personale DevOps di ogni organizzazione partner deve aggiungere un trust della relying party per le applicazioni Web accessibili attraverso i server AD FS.
• Il personale DevOps dell'organizzazione deve configurare il trust del provider di attestazioni per consentire ai server AD FS di considerare attendibili le attestazioni fornite dalle organizzazioni partner.
• Il personale DevOps dell'organizzazione deve inoltre configurare AD FS per passare le attestazioni alle applicazioni Web dell'organizzazione.

Per altre informazioni, vedere l'articolo su come stabilire una relazione di trust federativa.

Pubblicare le applicazioni Web dell'organizzazione e renderle disponibili ai partner esterni con la preautenticazione tramite i server WAP. Per altre informazioni, vedere Pubblicare applicazioni con la preautenticazione di ADFS

AD FS supporta il potenziamento e la trasformazione dei token. Microsoft Entra ID non fornisce questa funzionalità. Con AD FS, quando si configurano le relazioni di trust, è possibile:

• Configurare le trasformazioni delle attestazioni per le regole di autorizzazione. Ad esempio, è possibile eseguire il mapping della sicurezza dei gruppi da una rappresentazione usata da un'organizzazione partner non Microsoft a un elemento che Active Directory DS può autorizzare nell'organizzazione.
• Trasformare le attestazioni da un formato a un altro. È ad esempio possibile eseguire il mapping da SAML 2.0 a SAML 1.1 se l'applicazione supporta solo attestazioni SAML 1.1.

Monitoraggio AD FS

Il Management Pack Microsoft System Center per Active Directory Federation Services 2012 R2 offre il monitoraggio sia proattivo sia reattivo della distribuzione AD FS per il server federativo. Questo management pack esegue il monitoraggio di:

• Eventi che il servizio AD FS registra nel log eventi.
• Dati sulle prestazioni raccolti dai contatori delle prestazioni di AD FS.
• Integrità generale del sistema AD FS e delle applicazioni Web (relying party) e fornisce avvisi per problemi critici e avvertenze.

Un'altra opzione è Monitorare AD FS usando Microsoft Entra Connessione Health. Microsoft Entra Connessione Health offre un monitoraggio affidabile dell'infrastruttura di gestione delle identità locale. Consente infatti di mantenere una connessione affidabile a Microsoft 365 e Microsoft Online Services. Per garantire questa affidabilità, vengono usate funzionalità di monitoraggio per i componenti chiave delle identità, rendendo inoltre facilmente accessibili i punti dati chiave relativi a questi componenti.

Considerazioni

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

Efficienza prestazionale

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

Le considerazioni seguenti, riepilogate dall'articolo Pianificazione della distribuzione di ADFS, offrono un punto di partenza per il ridimensionamento delle farm di AD FS:

• Se si hanno meno di 1000 utenti, non creare server dedicati, ma installare AD FS in ognuno dei server Active Directory DS nel cloud. Assicurarsi di avere almeno due server di dominio Active Directory DS per gestire la disponibilità. Creare un singolo server WAP.
• Se sono presenti tra 1000 e 15.000 utenti, creare due server AD FS dedicati e due server WAP dedicati.
• Se sono presenti tra 15.000 e 60.000 utenti, creare tra tre e cinque server AD FS dedicati e almeno due server WAP dedicati.

Queste considerazioni presuppongono che si usino dimensioni di macchina virtuale dual quad core (standard D4_v2 o superiori) in Azure.

Se si usa il Database interno di Windows per archiviare i dati di configurazione di AD FS, la farm è limitata a otto server AD FS. Se si prevede di avere più bisogno in futuro, usare SQL Server. Per altre informazioni, vedere Ruolo del database di configurazione di AD FS.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

Creare una farm AD FS con almeno due server per aumentare la disponibilità del servizio. Usare account di archiviazione diversi per ogni VM AD FS nella farm. Questo approccio consente di garantire che un errore in un singolo account di archiviazione non renda inaccessibile l'intera farm.

Creare set di disponibilità di Azure separati per le macchine virtuali WAP e AD FS. Verificare che in ogni set siano presenti almeno due macchine virtuali. Ogni set di disponibilità deve avere almeno due domini di aggiornamento e due domini di errore.

Configurare i servizi di bilanciamento del carico per le macchine virtuali AD FS e WAP come segue:

• Usare un bilanciamento del carico di Azure per fornire l'accesso esterno alle macchine virtuali WAP e un bilanciamento del carico interno per distribuire il carico tra i server AD FS nella farm.

• Passare solo il traffico presente sulla porta 443 (HTTPS) ai server AD FS/WAP.

• Assegnare un indirizzo IP statico al bilanciamento del carico.

• Creare un probe di integrità usando HTTP in /adfs/probe. Per altre informazioni, vedere Hardware Load Balancer Health Checks and Web Application Proxy / AD FS 2012 R2 (Controlli di integrità del servizio Load Balancer hardware e Proxy applicazione Web/AD FS 2012 R2).

  Nota

  I server AD FS usano il protocollo SNI (Server Name Indication), pertanto il tentativo di eseguire il probe tramite un endpoint HTTPS dal bilanciamento del carico non riesce.

• Aggiungere un record DNS A al dominio per il bilanciamento del carico di AD FS. Specificare l'indirizzo IP del bilanciamento del carico e assegnargli un nome nel dominio (ad esempio adfs.contoso.com). Si tratta del nome usato dai client e dai server WAP per accedere alla farm di server AD FS.

È possibile usare SQL Server o il database interno di Windows per memorizzare le informazioni di configurazione di AD FS. Il database interno di Windows fornisce la ridondanza di base. Le modifiche vengono scritte direttamente in uno solo dei database di AD FS nel cluster AD FS, mentre gli altri server usano la replica pull per mantenere aggiornati i database. L'uso di SQL Server consente di ottenere le ridondanza completa del database e disponibilità elevata tramite il clustering di failover o il mirroring.

Sicurezza

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

AD FS usa HTTPS, pertanto verificare che le regole NSG per la subnet contenente le macchine virtuali del livello Web consentano le richieste HTTPS. Queste richieste possono avere origine dalla rete locale, dalle subnet contenenti il livello Web, dal livello business, dal livello dati, dalla DMZ privata, dalla DMZ pubblica e dalla subnet contenente i server AD FS.

Evitare l'esposizione diretta dei server AD FS a Internet. I server AD FS sono computer appartenenti a un dominio con autorizzazione completa di concedere token di sicurezza. Se un server viene compromesso, un utente malintenzionato può rilasciare token di accesso completo a tutte le applicazioni Web e a tutti i server federativi che sono protetti da AD FS. Usare i server WAP se il sistema deve gestire richieste di utenti esterni che non si connettono da siti partner attendibili. Per altre informazioni, vedere Dove posizionare un Proxy Server federativo.

Posizionare i server AD FS e WAP in subnet separate con i propri firewall. È possibile usare le regole NSG per definire le regole del firewall. Tutti i firewall devono consentire il traffico sulla porta 443 (HTTPS).

Limitare l'accesso diretto ai server AD FS e WAP. Solo il personale DevOps deve essere in grado di connettersi. Non aggiungere i server WAP al dominio.

È consigliabile usare un set di appliance virtuali di rete che registra informazioni dettagliate sul traffico che attraversa il perimetro della rete virtuale a fini di controllo.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

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

AD Domain Services

Valutare se scegliere Active Directory Domain Services come servizio condiviso utilizzato da più carichi di lavoro per ridurre i costi. Per altre informazioni, vedere prezzi di Dominio di Active Directory Services.

Active Directory Federation Services

Per informazioni sulle edizioni offerte da Microsoft Entra ID, vedere Prezzi di Microsoft Entra. La funzionalità Ad Federation Services è disponibile in tutte le edizioni.

Eccellenza operativa

Il personale DevOps deve essere preparato per eseguire le attività seguenti:

• Gestire i server federativi, inclusa la gestione della farm AD FS, la gestione dei criteri di attendibilità nei server federativi e la gestione dei certificati usati dai servizi federativi.
• Gestire i server WAP, inclusa la gestione della farm e dei certificati WAP.
• Gestire le applicazioni Web, inclusa la configurazione di relying party, metodi di autenticazione e mapping delle attestazioni.
• Eseguire il backup dei componenti di AD FS.

Per altre considerazioni su DevOps, vedere DevOps: Estensione di Dominio di Active Directory Services (AD DS) ad Azure.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Sarah Parkes | Senior Cloud Solution Architect

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Documentazione di Azure Activity Directory
• Gestire l'identità nelle applicazioni multi-tenant
• Sicurezza di Identity Management
• Firewall di Azure

Risorse correlate

• Distribuire Active Directory Domain Services in una rete virtuale di Azure
• Gestione delle identità e degli accessi di Microsoft Entra per AWS