Due nuovi servizi ibridi di Microsoft semplificano drasticamente la connessione di Active Directory ad Azure

Microsoft ha recentemente annunciato l’anteprima pubblica di due nuove importanti funzionalità che renderanno l’integrazione di Active Directory on-premise con Azure AD molto, molto più semplice. L'autenticazione passthrough (PTA) e il Single Sign-On senza soluzione di continuità (che ho deciso di chiamare 3SO) consentiranno ai vostri utenti di accedere facilmente alle applicazioni di Azure AD, come Office 365, senza dover installare una complessa farm di Active Directory Federation Services (AD FS) nel vostro data center né sincronizzare gli hash delle password degli utenti con Azure AD.

O, nel caso di 3SO, di installare qualcosa di extra.

Scelte di autenticazione ibrida fino ad oggi (e loro limiti)

La stragrande maggioranza delle aziende oggi utilizza Active Directory come servizio di identità fondamentale, e questa situazione non è destinata a cambiare nel breve termine. Pertanto, un primo passo fondamentale quando si pianifica di utilizzare uno qualsiasi dei servizi online di Microsoft è integrare Active Directory on-premise con Azure AD per ottenere due funzionalità. Innanzitutto, è necessario sincronizzare gli account e i gruppi di AD con Azure AD utilizzando Azure AD Connect. In secondo luogo, una volta che gli account si trovano in Azure AD, è necessario scegliere come autenticare gli utenti in tale ambiente. In questo post mi concentrerò proprio sugli aspetti relativi all’autenticazione degli utenti.

Oggi Microsoft offre due opzioni di autenticazione: AD FS, che fornisce la federazione delle identità (e una serie di altre funzionalità) per l’SSO, e la sincronizzazione delle password (“PHS” nei grafici sottostanti). Questa seconda opzione, nota agli esperti di tecnologia come sincronizzazione dell’hash delle password (da cui la “H”), offre una funzionalità di “accesso unico” in cui l’utente deve inserire le credenziali una seconda volta per accedere ad Azure AD, ma si tratta dello stesso ID utente e della stessa password utilizzati per Active Directory.

Il responsabile del programma di autenticazione passthrough di Microsoft, Ross Adams, rappresenta le differenze tra queste soluzioni in questo intelligente grafico dei benefici/dolori (Figura 1):

In ordine crescente di complessità e valore, abbiamo

• Account esclusivamente cloud: gli account utente vengono gestiti e autenticati in Azure AD. In questo articolo ci occuperemo di soluzioni ibride, quindi tralasceremo questo aspetto.
• AAD Connect / Account cloud: è possibile utilizzare Azure AD Connect per sincronizzare gli account utente con Azure AD, in modo che l'ID di accesso (di solito l'indirizzo e-mail dell'utente) rimanga lo stesso, ma gli utenti devono gestire autonomamente le proprie password nel servizio cloud. Non mi risulta che nessuno lo faccia.
• AAD Connect + PHS: quando si attiva la funzione opzionale di sincronizzazione degli hash delle password in Azure AD Connect, gli hash delle password degli utenti memorizzati nell'Active Directory on-premises saranno sincronizzati in Azure AD, consentendo così lo stesso signon.
• AAD Connect + AD FS: la soluzione più completa e più complessa con un buon margine, questa combinazione fornisce l'SSO ad Azure AD, autenticando gli account nella Active Directory locale.

Come potete vedere, esiste un notevole divario in termini di complessità di implementazione per introdurre un vero e proprio SSO nella vostra organizzazione. Le soluzioni di terze parti offerte da Okta, Ping Identity, OneLogin, Centrify, OptimalIDM e altri fornitori offrono metodi di autenticazione più semplici che colmano questo divario, e questo è uno dei motivi della loro popolarità.

Dominio unito a Windows... e a tutto il resto

Per comprendere cosa offrono queste due nuove soluzioni in anteprima pubblica, è utile raggruppare i casi d'uso dell'autenticazione in due categorie: il client che deve essere autenticato da Azure AD dispone di un ticket Kerberos oppure non ne dispone.

Il primo è il classico scenario di autenticazione aziendale di Windows, noto come Autenticazione integrata di Windows (IWA). Un utente che ha effettuato l’accesso alla propria workstation Windows, membro del dominio, con un account AD, sulla rete aziendale (ovvero la workstation è in grado di individuare un controller di dominio) e che quindi dispone di un ticket Kerberos, ottiene un accesso senza interruzioni alle risorse compatibili con AD senza che gli venga richiesto di inserire la propria password. Questo scenario esiste sin dalla nascita di Active Directory.

Il secondo settore rappresenta gli altri scenari di autenticazione che si sono evoluti da allora:

• Una workstation unita al dominio che tenta di autenticarsi dall'esterno della rete (il notebook)
• Un client basato su browser, sia esso su un dispositivo desktop o mobile (il browser web)
• Un client basato su API, come un'applicazione Office (l'applicazione mobile)

Esaminiamo innanzitutto lo scenario delle workstation aderenti al dominio e l'elegante soluzione proposta da Microsoft che utilizza 3SO.

Che cos'è il Seamless Single Sign-On?

3SO è stato progettato per funzionare con il primo bucket: il PC collegato al dominio nella rete aziendale. L'eleganza della soluzione 3SO può essere riassunta in poche parole: Azure AD può ora supportare l'autenticazione Kerberos.

Ecco tutto. In sostanza, lo scopo principale di AD FS è quello di trasformare un ticket Kerberos in un moderno token di sicurezza SAML o OAuth che possa essere utilizzato da una parte affidabile come Azure AD. Se Azure AD è in grado di interpretare un ticket Kerberos – in particolare un ticket di servizio per una risorsa Azure – non è necessario ricorrere ad AD FS come intermediario per effettuare la conversione.

La Figura 2 illustra come avviene questo processo. Azure AD viene rappresentato nel proprio AD locale semplicemente come un altro computer; AD non percepisce alcuna differenza. All'AD viene aggiunto un account computer (AZUREADSSOACCT) e, con esso, due SPN (nomi principali di servizio) contenenti gli URL necessari per eseguire l'autenticazione. La chiave segreta Kerberos per l'account della workstation viene condivisa in modo sicuro con Azure AD. Da questo momento in poi, i client utilizzano IWA per accedere alle risorse di Azure proprio come farebbero per accedere a un server IIS nel proprio data center locale.

1. Un utente tenta di accedere a una risorsa di Azure AD, ad esempio Office 365. Azure AD chiede all'utente di fornire un ticket di servizio Kerberos.
2. Il client presenta il suo TGT (ticket-granting ticket) e l'SPN del server di destinazione (un URL di Azure AD in questo caso) al suo controller di dominio.
3. Il servizio di emissione dei ticket (TGS) all'interno del centro di distribuzione delle chiavi (KDC) del controller di dominio crea un ticket di servizio per la risorsa Azure AD e lo restituisce al client.
4. Il client presenta il ticket di servizio ad Azure AD. Se il ticket è valido, l'utente viene autenticato.

Si noti che questa procedura non implica che l'utente sia autorizzato ad accedere alla risorsa, ma solo che abbia confermato la propria identità. Di conseguenza, a un utente Windows aziendale all'interno della rete non viene richiesto di inserire una password per accedere alle risorse di Azure AD e AD FS non è necessario. Niente male, vero?

L'installazione di 3SO non potrebbe essere più semplice: basta selezionare la casella "Abilita Single Sign-On" nella configurazione personalizzata dell'ultima versione di AD Connect.

Clienti supportati

Esistono diverse configurazioni supportate per 3SO. Innanzitutto, deve trattarsi di un client che supporti Kerberos, come Windows. In secondo luogo, funziona per accedere alle risorse di Azure AD tramite browser (ad esempio https://outlook.office.com) o da un client Office che supporti l’autenticazione moderna. È possibile consultare l'elenco dei client supportati, ma in sostanza è supportato su tutti i principali browser (IE, Chrome, Firefox) eccetto Edge e su tutti i sistemi operativi client Microsoft supportati. Microsoft consiglia di abilitare 3SO per tutti i client; se l'utente si trova in una configurazione non supportata, la cosa peggiore che potrà accadere è che gli venga richiesta la password.

Che cos'è l'autenticazione passante?

Il PTA è progettato per quei casi in cui il client non dispone di un ticket Kerberos, sia perché il client Kerberos non riesce a connettersi a un DC (ad esempio quando un dipendente lavora da casa sul proprio notebook aziendale), sia perché il client non supporta Kerberos (ad esempio un browser mobile o un'app che non supporta l'autenticazione moderna).

Non mi soffermerò qui sulle modalità di installazione di PTA, ma in sostanza si tratta di distribuire uno o più connettori leggeri on-premises, molto simili al connettore Azure AD Application Proxy, su server membri del dominio dove possano comunicare con un DC.

Ad alto livello, il processo di autenticazione PTA è molto simile al processo di autenticazione AD FS: Azure AD riconosce che la richiesta di autenticazione è delegata a una Active Directory on-premises tramite un proxy. Per AD FS, agisce come proxy. Per PTA, i connettori fungono da proxy (Figura 3).

1. Azure AD chiede all'utente di autenticarsi e l'utente inserisce l'indirizzo e-mail e la password.
2. Azure AD rileva che il dominio dell'utente è configurato per PTA; Azure AD invia una notifica al connettore, che recupera le credenziali.
3. Il connettore autentica l'utente rispetto ad AD utilizzando la stessa API di Windows utilizzata da AD FS.
4. La risposta viene restituita al connettore.
5. Il connettore inoltra la risposta ad Azure AD.
6. Azure AD rilascia un token all'utente.

Come si vede, questa soluzione presenta molti vantaggi rispetto ad AD FS:

• I connettori possono essere installati su server o DC esistenti, uniti al dominio.
• Quando sono installati più connettori (raccomandato), PTA esegue automaticamente il bilanciamento del carico su tutti i connettori.
• Tutte le connessioni Azure sono in uscita e nessun punto finale non autenticato è esposto a Internet.
• La gestione tramite il portale di Azure è molto semplice e non ci sono certificati da gestire

Quando si desidera utilizzare ancora AD FS?

Non fraintendetemi: AD FS non è stato assolutamente messo da parte. PTA è una freccia molto specializzata per un unico obiettivo: consente ad Azure AD di autenticare gli utenti di Active Directory rispetto all'AD aziendale, punto. Avete ancora bisogno di AD FS se

• Si desidera utilizzare le smartcard per l'autenticazione
• Si desidera utilizzare fornitori MFA di terze parti
• La politica di sicurezza aziendale prevede che le password rimangano sempre all'interno dell'infrastruttura locale (a differenza di AD FS, in PTA la password dell'utente viene inserita in Azure AD prima di essere trasferita all'interno dell'infrastruttura locale)
• Si utilizzano le regole di autenticazione aggiuntive di AD FS per imporre l'accesso condizionato.
• Si utilizza l'accesso condizionato a Windows 10 on-premises in base al dispositivo

E, naturalmente, è necessario disporre di AD FS se si hanno parti affidabili configurate localmente per fornire l'autenticazione SSO che non si desidera trasferire su Azure AD.

AD FS 2016 offre anche nuove funzionalità, come il supporto Azure MFA integrato; se avete un'implementazione AD FS esistente, valutate molto attentamente le vostre esigenze future e ciò che AD FS è in grado di fare prima di considerare di eliminarlo come misura di risparmio.

Scelte di autenticazione ibrida ora

Microsoft offre ora una serie molto più completa di opzioni di autenticazione ibrida (Figura 4):

Le opzioni originali sono ancora disponibili, ma ora è possibile ottenere grandi vantaggi con una complessità aggiuntiva minima. Se si utilizza la sincronizzazione delle password, l'aggiunta di 3SO eliminerà i problemi legati alle password per gli utenti aziendali all'interno della rete. Se invece si abilita PTA insieme a 3SO, si ottiene praticamente lo stesso valore di AD FS per quel caso d'uso specifico di autenticazione di Azure AD.

Con l'anteprima pubblica di 3SO e dell'autenticazione passthrough, Microsoft ha notevolmente ridotto gli ostacoli all'adozione di una strategia di identità ibrida che utilizza gli strumenti nativi dell'azienda. Infatti, questi strumenti sono persino più semplici da usare rispetto alle soluzioni di terze parti che hanno sfruttato la complessità di AD FS.

E, nel caso non fosse chiaro, tutto questo è gratuito. Microsoft ha puntato il proprio futuro sui servizi cloud Azure. L’azienda vuole rendere l’adozione di questi servizi il più semplice possibile e, nell’odierno mondo incentrato su Active Directory, ciò significa rendere l’integrazione di AD con Azure AD rapida e indolore. Ci è voluto un’eternità per portare alla luce queste funzionalità, ma prevedo che diventeranno rapidamente il ponte più popolare tra l’identità Microsoft on-premise e quella nel cloud.