• Guide, Sistemi Operativi
• 21 Giugno 2018

Gli Active Directory Federation Services (ADFS) permettono di identificare, autenticare ed autorizzare gli utenti e di offrire il web single sign-on per applicazioni che non sono ospitate nei server del vostro dominio.

Supponete infatti di voler utilizzare un applicativo web creato da un’azienda esterna alla vostra organizzazione (Resource Partner) e di non voler comunicare a questa azienda username e password dei vostri utenti di dominio (Account Partner). ADFS vi permette di reindirizzare le autenticazioni per l’applicazione web verso il vostro Federation Server e di usare il vostro domain controller come database per le autenticazioni. Basta quindi installare due Federation Server ed aprire un’unica porta (il traffico tra i server è HTTPS) per poter avere la possibilità di loggarsi senza reinserire le credenziali e allo stesso tempo non doverle comunicare a nessuno.

Figura 1: Principio di funzionamento di ADFS

In questo articolo mi occuperò della configurazione di una nuova Farm ADFS in Windows Server 2016. Per conoscere tutte le novità della nuova versione di ADFS vi rimando alla lettura dell’articolo What’s new in Active Directory Federation Services per Windows Server 2016

Prima però di avventurarci nella configurazione vera e propria della nostra Farm ADFS vi consiglio di leggere l’articolo Checklist: Deploying a Federation Server Farm e l’articolo Best practices for securing Active Directory Federation Services

L’infrastruttura tipica di una Farm ADFS è quella presentata nella figura 2. All’interno della LAN abbiamo il domain controller e le macchine in dominio, tra cui i server ADFS, mentre nella DMZ abbiamo il Web Application Proxy, che rimarrà in workgroup e che si occuperà di proteggere le connessioni da Internet verso il server ADFS.

Figura 2: Infrastruttura di ADFS che verrà realizzata

Gestione dei certificati per il Namespace ADFS

Come prima operazione procuratevi un certificato digitale per il nome del vostro ADFS Namespace. Utilizzate le informazioni contenute alla pagina Requisiti del certificato per ADFS per conoscere le caratteristiche che deve avere il certificato da installare su tutti i server della vostra infrastruttura ADFS, compresi i Web Application Proxy.

NOTA: Tutti i server ADFS e i server Web Application Proxy necessitano di un certificato SSL per soddisfare le richieste HTTPS per il servizio federativo. Il certificato da installare deve essere esattamente lo stesso su tutti i server dell’infrastruttura ADFS.

Nel mio caso utilizzerò il certificato con il nome sts.nicolaferrini.cloud. Dopo che avrete installato lo stesso certificato sia sulla macchina ADFS (in dominio) che sulla macchina Web Application Proxy (in workgroup) potete procedere con la configurazione del server ADFS

Requisiti per il dominio

ADFS 2016 richiede che il controller del dominio sia almeno Windows Server 2008 (il livello funzionale del dominio può invece essere ancora Windows Server 2003) e che tutte le macchine ADFS della Farm siano joinate allo stesso dominio. Per la creazione della Farm ADFS potete utilizzare uno standard service account oppure un Group Managed Service Account (gMSA). Per utilizzare un gMSA è necessario che i domain controller sia almeno Windows Server 2012 e uno dei vantaggi più evidenti del loro utilizzo è che la password dell’account viene aggiornata automaticamente.

Io preferisco utilizzare i Group Managed Service Account (gMSA),
e poiché sto usando un ambiente nuovo ed è la prima volta che ne creo uno devo prima creare la Key Distribution Services KDS Root Key, necessaria al domain controller per generare le password dei gMSA. Per poter creare la chiave è sufficiente eseguire, con privilegi elevati, in un domain controller il seguente comando PowerShell

I domain controller aspetteranno fino a 10 ore dal momento della creazione della chiave prima di poter permettere la creazione di un Group Managed Service Account (gMSA), in modo tale da consentire a tutti i domain controller presenti nel dominio di poter replicare la chiave appena creata. In un ambiente di laboratorio potete accelerare questa operazione eseguendo con privilegi elevati in un domain controller il seguente comando PowerShell:

Figura 3: Creazione della Key Distribution Services KDS Root Key per la generazione delle password dei Group Managed Service Account (gMSA).

Requisiti per il database di ADFS

Per l’installazione di ADFS è possibile utilizzare sia il Windows Internal Database (WID) che Microsoft SQL Server (sono supportate le versioni SQL Server 2008 e successive). Per maggiori informazioni vi rimando alla lettura dell’articolo Requisiti del database di configurazione di una Farm ADFS. In questo articolo utilizzerò il Windows Internal Database.

Installazione del primo server della Farm ADFS

Aprite il Server Manager in Windows Server 2016 e lanciate il wizard per l’aggiunta di un nuovo ruolo. Io sto utilizzando la macchina ADFS1.cloud. lab, che ho joinato al dominio, e procedo all’installazione del ruolo di Active Directory Federation Services, come mostrato in figura:

Figura 4: Installazione del ruolo Active Directory Federation Services

Figura 5: Riepilogo delle funzionalità offerte dal ruolo ADFS

Figura 6: Installazione del ruolo ADFS completata

Cliccando sul collegamento Configure the federation service in this server potrete lanciare il wizard che vi permetterà di creare il primo server della vostra Farm ADFS. Verificate anche dal link AD FS prerequisites di aver completato tutti i prerequisiti d’installazione e procedete cliccando su Next.

Figura 7: Creazione del primo Federation Server nella Farm

Figura 8: Account di dominio da utilizzare per la configurazione del server ADFS

Nella schermata successiva scegliete dal menù a tendina il certificato da utilizzare (che dovrete aver precedentemente installato) ed il Federation Service Name, che vi servirà successivamente per configurare il Web Application Proxy. Indicate anche il nome da visualizzare nella pagina di autenticazione di ADFS.

Figura 9: Certificato, Federation Service Name e nome della Farm ADFS da creare

Nella schermata successiva specificate il Service Account che farà girare i servizi ADFS. Utilizzerò, come già detto, un Group Managed Service Account chiamato ADFSservice

Figura 10: Creazione del Group Managed Service Account

Figura 11: Utilizzo del Windows Internal Database (WID)

Figura 12: Schermata riassuntiva delle configurazioni scelte

Figura 13: Controllo dei prerequisiti

Figura 14: Configurazione della Farm ADFS completata

La creazione della Farm ADFS è completata, ma è necessario riavviare la macchina. Notate alcuni warning che mi sono apparsi nella schermata finale. I warning si riferiscono ad alcuni nomi che mancano nel certificato (certauth.sts.nicolaferrini.cloud e enterpriseregistration.nicolaferrini.cloud). La mancanza di questi nomi non permetterà di registrare i dispositivi tramite ADFS e non permetterà l’autenticazione tramite certificato (novità della versione 4.0 di ADFS). Ricordatevi quindi di utilizzare certificati di tipo SAN con tutti i nomi. Il certificato corretto da utilizzare nel mio dominio avrebbe dovuto includere questi nomi:

• Subject Name (CN): sts.nicolaferrini.cloud
• Subject Alternative Name (DNS): sts.nicolaferrini.cloud
• Subject Alternative Name (DNS): certauth.sts.nicolaferrini.cloud
• Subject Alternative Name (DNS): enterpriseregistration.nicolaferrini.cloud

Dopo il riavvio potete connettervi alla AD FS Management console e verificare le configurazioni del vostro server. Aprendo le proprietà potrete accertarvi di aver utilizzato i nomi corretti, come mostrato in figura:

Figura 15: ADFS Management console e Federation Service Properties

Creazione della zona DNS e record per il server ADFS

Per permettere la corretta risoluzione dei nomi del server ADFS ho creato nel domain controller una zona con il nome pubblico nicolaferrini.cloud e ho creato un record host per sts.nicolaferrini.cloud, in modo tale che le macchine interne sappiano come contattare il server ADFS. Il dominio interno ed il dominio esterno infatti differiscono ed è necessario configurare correttamente la risoluzione dei nomi.

Figura 16: Creazione della zona e del record DNS per il server ADFS

Verifica della funzionalità ed accesso alla pagina di Sign-In

ADFS in Windows Server 2016 disabilita di default la pagina idpinitiatedsignon, utile per testare se l’installazione è avvenuta correttamente. È possibile riabilitarla lanciando sul server ADFS il comando Powershell, eseguito con privilegi elevati

Figura 17: Abilitazione della pagina idpinitiatedsignon

Collegatevi quindi all’indirizzo https://<FQDN DEL SERVER ADFS>/adfs/ls/idpinitiatedsignon.htm per verificare che tutto funzioni. Nel mio caso ho digitato l’indirizzo https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm e ho potuto verificare di avere accesso alla pagina di Sign-In

Figura 18: Verifica dell’accesso alla pagina di Sign-In

È anche possibile verificare che sia attivo l’url relativo ai Federation Service Metadata collegandosi a https://<FQDN DEL SERVER ADFS>/federationmetadata/2007-06/federationmetadata.xml. Nel mio caso ho utilizzato l’indirizzo https://sts.nicolaferrini.cloud/federationmetadata/2007-06/federationmetadata.xml

Figura 19: Verifica dell’accesso ai Federation Service Metadata

Aggiunta dei altri server ADFS alla Farm esistente

In caso il server ADFS non funzionasse i vostri utenti non potrebbero loggarsi. È quindi opportuno aggiungere un ulteriore server alla Farm ADFS che avete appena realizzato. La procedura è ben descritta nell’articolo Add a Federation Server to a Federation Server Farm. Dopo aver aggiunto il secondo server alla Farm sarà necessario anche utilizzare un bilanciatore di carico a monte dei due server per assicurarne l’alta disponibilità. Ulteriori informazioni sono disponibili alla pagina Load Balancer Requirements for ADFS 2016

Installazione del Web Application Proxy

Il Web Application Proxy (WAP), da installare in DMZ e da lasciare in Workgroup, è necessario per proteggere i server ADFS ed evitare di esporli direttamente ad Internet. Il WAP si comporta da Reverse Proxy e permette l’accesso sicuro alle applicazioni on-premises dall’esterno dell’infrastruttura aziendale. Maggiori dettagli sono disponibili nell’articolo Web Application Proxy in Windows Server 2016

Prerequisiti per la configurazione del proxy

• Installare esattamente lo stesso certificato che avete installato sui server ADFS
• Assicurarsi che il WAP possa risolvere il nome interno del vostro server ADFS o del VIP del vostro Load Balancer
• Creare un record DNS pubblico per il WAP, in modo tale che possa essere contattato dall’esterno
• Aprire le porte del firewall (la porta 443 per l’HTTPS deve essere aperta dall’esterno verso il WAP e dal WAP verso ADFS)

Installazione del Web Application Proxy

L’installazione del Web Application Proxy è molto semplice. Dal Server Manager lanciate il wizard per aggiungere un nuovo ruolo e scegliete il ruolo Remote Access, come mostrato in figura:

Figura 20: Aggiunta del ruolo Remote Access, necessario per l’installazione del Web Application Proxy

Figura 21: Descrizione delle funzionalità offerta dal ruolo Remote Access

Scegliete di installare il role service Web Application Proxy e aggiungete tutte le funzionalità richieste dal ruolo

Figura 22: Installazione del role service Web Application Proxy

Figura 23: Installazione del ruolo completata

Fate clic sul link Open the Web Application Proxy Wizard per lanciare la configurazione del WAP

Figura 24Web Application Proxy Configuration Wizard

Indicate quale sarà il server ADFS a cui dovrà puntare il WAP quando riceverà le richieste di autenticazione ed autorizzazione. Nel mio caso il server è sts.nicolaferrini.cloud

Figura 25: Configurazione del Federation Server da contattare

Figura 26: Scelta del certificato digitale

Figura 27: Comandi PowerShell che verranno eseguiti per la configurazione del WAP

Terminata la configurazione potrete aprire la Remote Access Management console e verificare che tutti i servizi siano perfettamente funzionanti, come mostrato in figura:

Figura 28: Remote Access Management console

Accesso dall’esterno dell’organizzazione

Per verificare che tutto funzioni perfettamente potete collegarvi da una macchina ESTERNA alla vostra infrastruttura e collegarvi al WAP. Modificate il DNS pubblico in modo tale che punti all’IP pubblico del WAP, controllate le configurazioni dei firewall e connettetevi al vostro server (nel mio caso sts.nicolaferrini.cloud) tentando di raggiungere la pagina idpinitiatedsignon, esattamente come avete fatto prima. Se avete configurato tutto correttamente vi collegherete al WAP che inoltrerà la richiesta al server ADFS (o al bilanciatore).

Figura 29: Connessione al server ADFS avvenuta dall’esterno dell’organizzazione, tramite WAP

Accesso dall’interno dell’organizzazione

Se provate a collegarvi da una macchina in dominio, usando qualsiasi browser, alla pagina di autenticazione https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm vi apparirà un messaggio che vi richiederà di inserire le credenziali. Per poter garantire l’accesso automatico dell’utente è prima necessario impostare nella Local Intranet l’url del Federation Server. Questa impostazione consente al browser di inviare automaticamente le credenziali dell’utente connesso sotto forma di un ticket Kerberos per AD FS.

Figura 30: Richiesta di credenziali anche dalla macchina in dominio

Figura 31: Aggiunta nelle Internet Options dell’url del Federation Server nei Local Intranet Trusted Sites

Se non usate Internet Explorer ma usate Google Chrome non avrete problemi perché per impostazione predefinita Chrome usa lo stesso insieme di URL di siti attendibili di Internet Explorer.

È anche possibile utilizzare una Group Policy per poter automatizzare questa impostazione. Ci basterà creare una nuova GPO da collegare al dominio e in User Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page dobbiamo modificare la voce Site to Zone Assignment List inserendo come VALUE NAME il nome del server ADFS e come  VALUE il numero1.

Figura 32: Aggiunta ai Trusted Sites dell’url del Federation Server tramite GPO centralizzata

Connessione tramite i browser Google Chrome, Mozilla Firefox e Microsoft Edge

Se volete effettuare la connessione da browser alternativi ad Internet Explorer sarà necessario, dopo aver inserito nella Local Intranet l’url del Federation Server, apportare alcune modifiche alla configurazione del server ADFS, come spiegato nell’articolo Configurazione autenticazione intranet basata su form per i dispositivi che non supportano WIA

Infatti sarà necessario modificare la lista dei client che possono supportare la Windows Integrated Authentication (WIA). Per farlo vi basterà eseguire sul server ADFS, da un prompt di PowerShell eseguito con privilegi elevati, i seguenti comandi:

Figura 33: Modifica dei client che supportano la WIA in ADFS

Configurazione di Active Directory Federation Service con Office 365

Per configurare AD FS 2016 con Office 365 è possibile utilizzare il tool Azure AD Connect, che si occuperà di automatizzare la procedura. Alla pagina Configurare AD FS 2016 ed Office 365 con Azure AD Connect trovate tutti i passaggi necessari per eseguire l’integrazione di AD FS 2016 con Azure AD e Office 365.

Active Directory Federation Services 2016 e Azure Multi-Factor Authentication

Tra le novità introdotte in Active Directory Federation Services (AD FS) in Windows Server 2016 c’è la possibilità di integrare l’autenticazione con Microsoft Azure Multi-Factor Authentication (MFA), in modo tale da inserire una One-Time Password (OTP) invece che la password di dominio. Alla pagina Active Directory Federation Services 2016 e Azure Multi-Factor Authentication troverete tutti gli step necessari ad integrare le due funzionalità.

Conclusioni

I vantaggi offerti dai Federation Services sono notevoli, perché permettono il Single Sign-On ed evitano che le password dei nostri utenti vengano memorizzate al di fuori della nostra organizzazione. Sia per motivi burocratici, che di privacy, sarebbe impossibile rivolgersi a fornitori di servizi esterni, che dovrebbero archiviare e gestire (e quindi mantenere aggiornate) le nostre credenziali. Con ADFS l’autenticazione avviene in azienda e i nostri dati sono al sicuro!