Nicola FerriniImplementare il Single Sign-On (SSO) con Azure AD
La maggior parte degli utenti vuole utilizzare un’unica password per poter accedere sia all’Active Directory locale che ai servizi che usano Azure AD, come ad esempio Office 365. Abbiamo visto in un precedente articolo, Come funziona Azure AD Pass-through Authentication, come poter fare in modo che l’autenticazione avvenga utilizzando il domain controller locale, nel caso non vogliamo replicare le nostre password in Azure AD. Utilizzare la stessa username e password sia all’interno che all’esterno della propria infrastruttura aziendale prende il nome di SAME SIGN-ON.
In questo articolo vedremo invece come implementare il SINGLE SIGN-ON (SSO), un’opzione che consente agli utenti di non dover digitare la password, ma solo il nome utente, per accedere ad Azure Active Directory.
SSO è una funzionalità che viene abilitata tramite il tool Azure AD Connect e funziona sia con la sincronizzazione delle password sia con l’autenticazione pass-through. Questo tipo di funzionalità però è disponibile solo se il computer da cui effettuiamo la connessione è joinato al dominio.
Vantaggi del Single Sign-on con autenticazione Pass-through di Azure AD
Sicuramente tra i vantaggi più evidenti di questo tipo di autenticazione spicca quello di evitare l’uso dei Federation Services, che prevedono una farm di almeno 2 Server ADFS nel Backend e 2 Server Web Application Proxy nella DMZ, per un totale di 4 server! Per avere un’idea di quanto sia complicata l’infrastruttura che usa ADFS potete dare un’occhiata all’articolo Checklist: Use AD FS to implement and manage single sign-on.
Come funziona
Il principio di funzionamento del Single Sign-On con Azure AD è molto semplice. Quando l’utente tenta di accedere ad una risorsa che usa Azure AD per l’autenticazione, come ad esempio il portale di Office 365, gli vengono chieste le credenziali. L’utente viene reindirizzato al portale di autenticazione https://login.microsoftonline.com e dopo aver inserito la propria username, viene reindirizzato verso il proprio domain controller. Active Directory restituisce un ticket Kerberos al client. Il client invia il ticket Kerberos acquisito da Active Directory ad Azure AD. Azure AD decrittografa il ticket Kerberos e restituisce un token all’utente, che lo riutilizza per poter accedere alla risorsa, come ad esempio il portale di Office365.
Il tutto avviene in maniera completamente trasparente per l’utente, che dopo aver inserito la username si ritrova autenticato senza aver dovuto inserire la password.
Figura 1: Principio di funzionamento del Single Sign-On (SSO)
Abilitazione di SSO con autenticazione pass-through
Single Sign-On è un’opzione che può essere abilitata utilizzando il tool Azure AD Connect tramite sincronizzazione delle password o autenticazione pass-through.
In questo articolo ci occuperemo di implementare il SSO con l’autenticazione pass-through.
Procediamo all’installazione di Azure AD Connect scaricando l’eseguibile dal link http://go.microsoft.com/fwlink/?LinkId=615771 e lanciamo il setup
Figura 2: Setup di Azure AD Connect
Scegliamo di installare Azure AD Connect in modalità personalizzata, cliccando su Customize, e nella schermata successiva facciamo clic su Install.
Figura 3: Installazione dei prerequisiti di Azure AD Connect
Dopo l’installazione dei componenti necessari, viene richiesta la selezione del metodo di accesso degli utenti. Scegliamo quindi la modalità Pass-Through Authentication e mettiamo il segno di spunta su Enable single sign-on, come mostrato in figura:
Figura 4: Single Sign-On con autenticazione pass-through
Inseriamo a questo punto le credenziali da Global Admin del nostro Tenant di Azure AD. Usate un utente creato nel Cloud, possibilmente un account del dominio onmicrosoft.com.
Figura 5: Connessione ad Azure AD
Nella schermata successiva inseriamo le credenziali di Enterprise Admin del nostro dominio di Active Directory locale.
Per poter utilizzare le stesse credenziali sia per il login in Active Directory che per il login in Azure AD è necessario che gli username e i suffissi UPN (User Principal Name) coincidano. Per questo motivo nella schermata successiva vi verranno mostrati i domini che sono stati verificati nel vostro Tenant di Azure AD. Verificate che i domini siano corretti, altrimenti procedete alla regsitrazione dei suffisso UPN utilizzando la console di Active Directory Domains and Trusts.
Figura 6: Verifica dei suffissi UPN e del domini verificati in Azure AD
Di default vengono sincronizzati tutti i domini della foresta e tutte le unità organizzative (OU). Per escludere alcuni domini o unità organizzative dalla sincronizzazione con Azure AD, è possibile deselezionarli. Io ho deciso di sincronizzare solo la OU chiamata Office365.
Figura 7: Scelta dei domini e delle OU da sincronizzare
Nella schermata relativa all’Identificazione univoca degli utenti lasciamo le configurazioni predefinite e facciamo clic su Next. Lasciamo tutte le impostazioni di default anche per la schermata Filter Users and Devices.
Figura 8: Parametri per l’identificazione univoca degli utenti
Figura 9: Scelta degli utenti o del gruppo da sincronizzare
Nella schermata delle Optional Features, poiché abbiamo scelto l’autenticazione Pass-through, l’opzione di sincronizzazione delle password è abilitata di default. Questa opzione non è obbligatoria e per alcune aziende è importante che le password non vengano portate nel Cloud. Decidiamo quindi di non selezionarla, come mostrato in figura:
Figura 10: Optional features
Quando si abilita Single Sign-On in Azure AD Connect, viene creato un account computer denominato AZUREADSSOACCT nell’Active Directory locale e la chiave di decrittografia di Kerberos è condivisa con Azure AD. Inoltre vengono creati due Service Principal Name (SPN) Kerberos per indicare gli URL del cloud usati durante l’autenticazione tra il client e Azure AD. Inseriamo a questo punto le credenziali di Domain admin appropriate per il nostro dominio, in modo tale che venga creato l’account computer AZUREADSSOACCT , come mostrato in figura:
Figura 11: Inserimento delle credenziali per la configurazione del computer account nell’ Active Directory locale
Cliccando su Next avremo completato la configurazione e subito dopo inizierà il processo di sincronizzazione con il nostro Tenant di Azure AD.
Figura 12: Completamento del processo di configurazione
Figura 13: Installazione completata
Figura 14: Account computer AZUREADSSOACCT creato nell’Active Directory locale
Per poter testare il funzionamento del Single SIGN-On ci basterà loggarci su uno dei client del dominio e accedere al portale di autenticazione di Azure AD https://login.microsoftonline.com
Per poter garantire l’accesso automatico dell’utente è prima necessario impostare nella Local Intranet del browser i due url:
Questa impostazione consente al browser di inviare automaticamente le credenziali dell’utente connesso sotto forma di un ticket Kerberos per Azure AD.
Apriamo Internet Explorer, clicchiamo sul simbolo della rotellina per aprire le Internet Options, spostiamoci nella scheda Security e selezioniamo Local Intranet. Dopo aver cliccato su Sites, clicchiamo su Advanced e si aprirà la schermata dove potremo inserire i due URL, come mostrato in figura:
Figura 15: Aggiunti esplicita all’area Intranet del computer dei due siti di autenticazione
Figura 16: Particolare dei due URL aggiunti alla Local Intranet
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
Facendo clic sul pulsante Show potremo inserire i due URL richiesti, come mostrato in figura:
Figura 17: URL e valori da inserire
Conclusioni
Il SINGLE SIGN-ON, in associazione all’autenticazione Pass-through, ci permette di avere le stesse funzionalità che fino ad ora erano possibili sono utilizzando gli Active Directory Federation Services, che richiedono diverse macchine per poter funzionare. Davvero una grossa novità ed un grosso vantaggio per autenticarsi in Azure AD senza dover sincronizzare le password in Azure AD.