ADFS vs. Azure AD: Come Microsoft ha cambiato il gioco di autenticazione
Addled da ADFS? Perplesso dalla sincronizzazione hash della password? Perplesso da passare attraverso l’autenticazione? Esploriamo come Azure AD sta lasciando l’autenticazione locale alle spalle.
Quando Microsoft ha lanciato Office 365 nel giugno 2011, uno dei primi requisiti era quello di fornire una qualche forma di single sign-on per gli utenti aziendali che accedevano alla piattaforma da un dominio pubblicitario.,
Ciò ha comportato il collegamento di Azure AD al servizio federativo fornito tramite ADFS e l’ANNUNCIO locale.
Da allora, l’adozione del cloud ha avuto un’enorme influenza sul modo in cui le organizzazioni moderne autenticano gli utenti. Qualsiasi affidamento sulla funzionalità locale è diventato un ostacolo, piuttosto che un aiuto.
Come tale, sempre più organizzazioni sono alla ricerca di modi per liberarsi dalle trappole della tecnologia legacy e sfruttare il Cloud senza causare interruzioni inutili.,
Ma questo non vuol dire che i metodi esistenti non abbiano i loro usi, il vantaggio finale del Cloud è avere la flessibilità di selezionare i metodi che meglio soddisfano le tue esigenze, quindi esaminiamo come le soluzioni di autenticazione cloud si sono evolute nel corso degli anni e i benefici che portano.
Da ADFS ad Azure AD Connect – e autenticazione cloud
La prima opzione di autenticazione cloud (anche se non il nostro approccio preferito) utilizzava la funzione “sincronizzazione hash password” di Azure AD Connect, consentendo agli utenti di autenticarsi direttamente nel cloud., Tuttavia, se ciò accadesse, gli utenti non sarebbero in grado di avere Single sign-on.
Poiché l’esperienza utente è importante per garantire che i servizi siano adottati, fornire single sign-on, basato sull’approccio hash della password, è stato un grosso problema. Pertanto, molte organizzazioni in tutto il mondo hanno implementato ADFS per garantire che gli utenti potessero accedere ai servizi di Office 365 nel modo più semplice possibile.
Due anni fa, le cose hanno iniziato a cambiare quando Microsoft ha iniziato a creare diversi metodi di single sign-on disponibili accanto a nuovi metodi di autenticazione.,
Autenticazione pass-through e single sign-on senza soluzione di continuità
Uno di questi metodi era Pass-through Authentication (PTA). PTA integra un accesso Web a Office 365 con una richiesta di autenticazione inviata ai controller di dominio AD.
Ciò significa che l’utente completa il modulo di accesso in Azure, ma l’ID e la password vengono ancora convalidati da AD dopo il passaggio attraverso il server Azure AD Connect. Quando Microsoft ha sviluppato questo, hanno anche inventato un nuovo metodo migliorato per fornire single sign-on.,
Questo nuovo “seamless single sign-on”, ha permesso ad Azure di accettare un ticket Kerberos per l’autenticazione. Questo token Kerberos è collegato all’ANNUNCIO originale in cui l’utente si è autenticato e può essere passato ad Azure per la convalida. Ciò significa che un utente che accede in locale e quindi tenta di accedere a Office 365 può essere autenticato con il token Kerberos, semplice e sicuro.
Tuttavia, PTA richiede ancora un componente locale., Questo viene inizialmente installato come agente sul server Azure AD Connect, ma può anche essere installato su server aggiuntivi per fornire una maggiore disponibilità – Microsoft consiglia almeno tre agenti di autenticazione su tre server per PTA.
È questo requisito locale che potrebbe essere problematico. Se la pipe di Internet non riesce, non ci sarà accesso a Office 365 fino a quando l’autenticazione non viene commutata solo su cloud o viene ripristinata la connettività Internet agli agenti di autenticazione.,
Video: perché migrare all’autenticazione di Azure?
Non essere schiavo dei processi di autenticazione locali. Guarda ora questo breve video per:
- Scopri le differenze nell’architettura di autenticazione federata rispetto a quella gestita
- Scopri gli approcci migliori per la migrazione dell’autenticazione
Guarda ora
Il meglio di entrambi – Una soluzione ibrida
Per evitare questa situazione, ora c’è un’altra opzione., Utilizzando password hash sync (PHS) significa che un utente può sempre autenticarsi direttamente contro Azure AD.
Questo è il metodo migliore per fornire un accesso coerente all’ambiente Office 365, ma sembrerebbe rimuovere la funzione di single sign-on necessaria agli utenti.
In questo caso, tuttavia, il PHS può essere integrato dalla funzione single sign-on senza soluzione di continuità. Azure AD può accettare lo stesso token Kerberos basato su annunci e non richiede all’utente di immettere ID e password.,
Gli utenti locali ottengono l’accesso utilizzando seamless Single Sign-on, mentre gli utenti che si trovano altrove richiederebbero la corretta combinazione di ID e password per accedere ai servizi.
In questo scenario, non vi è alcuna dipendenza da qualsiasi ambiente locale, in caso di un errore di Internet, tutti gli utenti esterni saranno ancora in grado di autenticarsi. Se l’ANNUNCIO interno non riesce, gli utenti saranno comunque in grado di utilizzare il loro ID e la password per accedere, anche se il token Kerberos non è disponibile.
Qual è la differenza?,
A questo punto, potrebbe valere la pena esaminare i pro e i contro relativi dei tre metodi di autenticazione.
Queste funzioni sembrano indicare che ADFS è ancora una buona scelta quando l’autenticazione deve essere solo locale (e non inserita in una pagina Web basata su cloud), o quando si determina se il dispositivo di un utente è interno o esterno.
Per tutti gli altri casi sarebbe preferibile l’uso di PTA o PHS., Poiché PHS fornisce una migliore disponibilità e non fa affidamento su elementi locali, è generalmente il metodo consigliato per l’autenticazione.
Trova ciò che funziona per te
Più recentemente (febbraio 2019), il NCSC hanno cambiato i loro consigli sulla protezione di Office 365 per utilizzare “cloud-native authentication”. Ciò significa implementare PHS e single sign-on senza soluzione di continuità. Il documento completo può essere trovato qui.
Per molte organizzazioni, ciò significa passare da un’implementazione ADFS all’utilizzo di PHS e single sign-on senza interruzioni.,
Il cambiamento sia nella sincronizzazione che nell’autenticazione dovrebbe essere affrontato con una certa cura per garantire che qualsiasi tempo di inattività sia ridotto al minimo.
Naturalmente, questo rimuove solo i requisiti di autenticazione di Office 365 dall’ambiente ADFS e non rimuove altre parti dipendenti, sebbene la maggior parte di questi dovrebbe essere in grado di essere spostata in Azure AD quando appropriato.
Passare da ADFS a password hash sync con single sign-on senza soluzione di continuità può sembrare un po ‘ spaventoso, ma ThirdSpace può aiutare ad accelerare il processo di migrazione.,
Ottenere consigli di esperti sul miglior metodo di autenticazione per la tua organizzazione specifica è importante, poiché ADFS ha ancora i suoi usi e potrebbe rivelarsi l’opzione migliore in alcune circostanze.
Assicurati di guardare il nostro breve video per avere maggiori dettagli sul perché molti stanno facendo il salto all’autenticazione basata su cloud.
Inoltre, scopri tutte le ultime notizie e le funzionalità in arrivo su Azure AD, Windows 10 e Office 365 con la nostra serie trimestrale di webinar di aggiornamento tecnologico Microsoft.