Microsoft ha recentemente annunciato l'anteprima pubblica di due nuove importanti funzionalità che renderanno l'integrazione di Active Directory on-premises con Azure AD molto, molto più semplice. L'autenticazione passante (PTA) e il Seamless Single Sign-On (io scelgo di chiamarlo 3SO) consentiranno ai vostri utenti di accedere facilmente alle applicazioni di Azure AD, come Office 365, senza dover installare una complicata farm di Active Directory Federation Services (AD FS) nel vostro data center o 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 ha Active Directory come servizio di identità di base, e non se ne andrà tanto presto. Pertanto, la prima operazione fondamentale da fare quando si intende utilizzare uno dei servizi online di Microsoft è integrare la propria Active Directory on-premises con Azure AD per due funzionalità. In primo luogo, è necessario sincronizzare gli account e i gruppi AD con Azure AD utilizzando Azure AD Connect. In secondo luogo, una volta che gli account sono in Azure AD, è necessario scegliere come autenticare gli utenti. In questo post mi concentrerò sull'autenticazione degli utenti.
Oggi Microsoft offre due possibilità 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 scelta, nota ai digerati come sincronizzazione dell'hash della password (da cui la "H"), fornisce una funzionalità di "same signon" in cui l'utente deve inserire le credenziali una seconda volta per accedere ad Azure AD, ma si tratta dello stesso userid e della stessa password che utilizza 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 solo cloud: Gli account utente sono gestiti e autenticati in Azure AD. In questo post parliamo di soluzioni ibride, quindi lasciamo perdere.
- AAD Connect / Account cloud: È possibile utilizzare Azure AD Connect per sincronizzare gli account utente in Azure AD in modo che l'id di accesso (di solito l'indirizzo e-mail dell'utente) sia lo stesso, ma gli utenti devono mantenere le proprie password nel servizio cloud. Non vedo nessuno che 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 si può notare, c'è un grande divario nella complessità dell'implementazione per ottenere un vero SSO nella vostra organizzazione. Le soluzioni di terze parti di Okta, Ping Identity, OneLogin, Centrify, OptimalIDM e altre offrono metodi di autenticazione più semplici che si adattano a questo divario, e questo è uno dei motivi della loro popolarità.
Dominio unito a Windows... e a tutto il resto
Per capire 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 ha un ticket Kerberos, oppure non ne ha uno.
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 unita al dominio con un account AD, sulla rete aziendale (cioè la workstation è in grado di trovare un controller di dominio) e quindi dispone di un ticket Kerberos, può accedere senza problemi alle risorse AD-aware senza che gli venga richiesto di inserire la password. Questo scenario esiste da quando è stato inventato 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 un client desktop o mobile (il browser web)
- Un client basato su API, come un'applicazione Office (l'applicazione mobile)
Esaminiamo prima lo scenario delle workstation unite al dominio e l'elegante soluzione di 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.
Tutto qui. Ridotto alla sua essenza, lo scopo principale di AD FS è quello di trasformare un ticket Kerberos in un moderno token di sicurezza SAML o OAuth che può essere utilizzato da una relying party come Azure AD. Se Azure AD è in grado di comprendere un ticket Kerberos, in particolare un ticket di servizio per una risorsa Azure, non è necessario l'intermediario AD FS per la traduzione.
La Figura 2 mostra come ciò avviene. Azure AD è rappresentato nell'AD locale come un altro computer; AD non conosce la differenza. Un account computer (AZUREADSSOACCT) viene aggiunto all'AD e con esso due SPN (service principal name) che contengono 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 potrebbero accedere a un server IIS nel data center locale.
- 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.
- 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.
- Il servizio di concessione 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.
- Il client presenta il ticket di servizio ad Azure AD. Se il ticket è valido, l'utente viene autenticato.
Si noti che questo processo non significa che l'utente sia autorizzato ad accedere alla risorsa, ma solo che si è autenticato. Il risultato è che a un utente Windows aziendale in rete non viene richiesto di inserire una password per accedere alle risorse di Azure AD e non è necessario AD FS. Davvero un'ottima soluzione, no?
L'installazione di 3SO è semplicissima: basta selezionare la casella "Abilita single sign on" nella configurazione personalizzata dell'ultima versione di AD Connect.
Clienti supportati
Ci sono un paio di configurazioni supportate per 3SO. Innanzitutto, deve trattarsi di un client che supporta 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 supporta l'autenticazione moderna. È possibile consultare l'elenco dei client supportati, ma essenzialmente è supportato da tutti i principali browser (IE, Chrome, Firefox) tranne Edge, e da tutti i sistemi operativi client Microsoft supportati. Microsoft consiglia di attivare il 3SO per tutti i client; se l'utente si trova in una configurazione non supportata, la cosa peggiore è che riceverà una richiesta di password.
Che cos'è l'autenticazione passante?
PTA è stato progettato per i casi d'uso in cui il client non dispone di un ticket Kerberos, sia perché il client Kerberos non può raggiungere un DC (ad esempio quando un dipendente lavora da casa con il proprio notebook aziendale), sia perché il client non supporta Kerberos (ad esempio un browser o un'applicazione mobile che non supporta l'autenticazione moderna).
Non parlerò qui di come installare PTA, ma essenzialmente si distribuiscono uno o più connettori leggeri on-premises, simili al connettore Azure AD Application Proxy, su server uniti al dominio dove possono 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).
- Azure AD chiede all'utente di autenticarsi e l'utente inserisce l'indirizzo e-mail e la password.
- Azure AD determina che il dominio dell'utente è configurato per il PTA; Azure AD informa il connettore che recupera le credenziali.
- Il connettore autentica l'utente rispetto ad AD utilizzando la stessa API di Windows utilizzata da AD FS.
- La risposta viene restituita al connettore.
- Il connettore inoltra la risposta ad Azure AD.
- 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.
- È molto semplice da gestire dal portale Azure 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 richiede che le password rimangano sempre in sede (a differenza di AD FS, in PTA la password dell'utente viene inserita in Azure AD prima di andare in sede).
- 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
Naturalmente, è necessario disporre di AD FS se si dispone di parti fidate configurate localmente per fornire SSO che non si desidera spostare 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 un grande valore con un minimo di complessità in più. Se si utilizza la sincronizzazione delle password, l'aggiunta di 3SO eliminerà le sfide delle password per gli utenti aziendali in rete. Se invece abilitate PTA insieme a 3SO, avrete praticamente lo stesso valore di AD FS per lo specifico caso d'uso dell'autenticazione Azure AD.
Con l'anteprima pubblica di 3SO e dell'autenticazione passthrough, Microsoft ha abbassato drasticamente la barriera all'adozione di una strategia di identità ibrida utilizzando gli strumenti nativi dell'azienda. In effetti, questi strumenti sono ancora più semplici da usare rispetto alle offerte di terze parti che hanno sfruttato la complessità di AD FS.
E se non fosse chiaro, tutto questo è gratuito. Microsoft ha scommesso il suo futuro sui servizi cloud Azure. L'azienda vuole rendere l'adozione di questi servizi il più semplice possibile, e nell'attuale mondo incentrato su Active Directory ciò significa rendere l'integrazione di AD con Azure AD rapida e indolore. Ci è voluta una vita per portare alla luce queste funzionalità, ma prevedo che diventeranno rapidamente il ponte di identità più popolare tra l'identità Microsoft on-premises e l'identità Microsoft in-the-cloud.
