• Cloud, Guide, Sicurezza
• 10 Agosto 2020

Il panorama tecnologico negli ultimi anni ha subito una drastica trasformazione: sempre più aziende fanno affidamento ai servizi Cloud (spesso senza saperlo, per saperne di più leggete l’articolo Controllare l’adozione del Cloud tramite Microsoft Cloud App Security). Questo non è un semplice cambio di fornitore di servizi IT ma è un approccio rinnovato rispetto a come vengono scritte le applicazioni e al modo di collaborare; il mondo di oggi è sempre più mobile-first e, di conseguenza, cloud-first.

Il fatto che gli asset tecnologici e la collaborazione non sono più contenuti (e limitati) all’interno della rete aziendale ha fatto cadere i presupposti della sicurezza informatica tradizionale basata sulla difesa del perimetro, adesso il nuovo perimetro è l’identità degli utenti: “Identity is the new perimeter“. Per proteggere questo nuovo perimetro si fa ricorso a tecnologie diverse come ad esempio la Multi Factor Authentication oppure a criteri di accesso come Conditional Access combinato con l’euristica intelligente di Identity Protection.

Per poter implementare questa nuova visione si è reso necessario ripensare gli schemi ed i protocolli di autenticazione utilizzati nel passato (Kerberos, NTLM, Digest, plaintext…) adottando nuove soluzioni tecnologiche nate appositamente per il Cloud (WS-Fed, SAML, OAuth…). All’interno di Microsoft 365 il supporto ai nuovi protocolli di autenticazione prende il nome di Modern Authentication.

Come avviene l’autenticazione legacy

Figura 1 – Autenticazione Kerberos

In Figura 1 è rappresentato uno dei flussi di autenticazione più classici e familiari: l’autenticazione Kerberos, inventata dal MIT nei tardi anni ’80 e fondamento dell’autenticazione all’interno di Active Directory. Nell’immagine sono riconoscibili tutte le fasi dell’autenticazione:

• 1-2: Kerberos Authentication Service Request/Response: il Client si autentica e riceve il Ticket Granting Ticket
• 3-4: Kerberos Ticket Granting Service Request/Response: il Client, che deve accedere ad un Servizio sul Server, richiede in base al Service Principal Name di quello specifico servizio un Ticket Grating Service
  
• 5-6: Kerberos Application Server Request/Response: il Client presenta il Ticket Granting Service al Servizio il quale è in grado di interpretarlo e di autorizzare o meno il Client

Un altro esempio classico è la proxy authentication, quello che accade in Exchange Online e qualsiasi applicazione che basi l’autenticazione su NTLM o LDAP:

Figura 2 – Proxy Auth

1. Outlook tenta di accedere alla cassetta postale, invia quindi le credenziali ad Exchange Online
2. Exchange Online verifica le credenziali presso Azure AD
   
3. Azure AD risponde ed al client viene concesso oppure negato l’accesso

Questi sono solo esempi dei protocolli di autenticazione consolidati all’interno delle reti on-premises, ma tutti condividono le stesse limitazioni:

• Non sono pensati per essere sicuri se trasportati su Internet
• È necessario che applicazione, client e server siano su reti in grado di parlarsi
• Spesso sono necessari dei “trust” che richiedono ampi privilegi e molte porte, spesso non proprio firewall-friendly
• L’applicazione deve avere al suo interno del codice per poter interagire con il sistema di autenticazione, e deve trattare i suoi package di autenticazione in maniera sicura (Kerberos AS, hash NTLM, coppia username/password in caso di integrazione LDAP diretta)
• Non sono estensibili

Quando una applicazione è coinvolta in questo genere di autenticazione deve essere lei stessa (in linea generale) a richiedere al client le credenziali: un esempio è Outlook in configurazione Legacy il quale sfrutta NTLM.

Figura 3 – Outlook Legacy Auth

Queste limitazioni hanno portato l’industria informatica a sviluppare nuovi standard di autenticazione che sorpassano i concetti e le limitazioni dell’epoca su cui si basavano i vecchi protocolli e introducono nuove e ricche funzionalità di autenticazione.

Come avviene la Modern Autentication

Figura 4 – Modello di passive authentication

In Figura 4 è rappresentato un modello generico di come avviene l’autenticazione tramite i nuovi protocollo di autenticazione, un po’ di terminologia:

• STS: Secure Token Service (a volte chiamato Idp, Identity Provider) è il servizio che fornisce i token di autenticazione, nel mondo Microsoft è Azure Active Directory oppure Active Directory Federation Services
• RP: Relying Party è il servizio che consuma questi token e può essere un altro STS oppure una applicazione
• Client: è l’applicazione client che tenta di accedere al Relying Party, assume il ruolo di Bearer, ovverosia portatore, in quanto “porta” il Security Token dal STS al RP.

Ecco come avviene:

1. Il Client cerca di accedere al Relying Party
2. Il Relying Party
   reindirizza il Client presso il STS
3. Il STS esegue la procedura di autenticazione
   
4. Il STS consegna il Security Token al Client
5. Il Security Token viene consegnato al Relying Party
6. Il Relying Party
   valida il Security Token tramite la firma digitale apposta dal STS

Questo flusso di autenticazione porta molti vantaggi, principalmente derivate dal fatto che le funzioni di autenticazione sono implementate interamente all’interno del STS, liberando le applicazioni da questa responsabilità.

Sempre prendendo Outlook come esempio, ecco come si presenta il prompt di autenticazione quando si sta utilizzando la Modern Authentication: come è possibile osservare non è più Outlook a richiedere le credenziali ma vengono richieste direttamente dal STS (Azure AD).

Figura 5 – Outlook Modern Auth

Modern Authentication – Under the Hood

Utilizzando uno strumento come Fiddler è possibile analizzare i singoli passi che avvengono durante il processo di autenticazione. I numeri riportati nelle immagini sono corrispondenti a quelli nella Figura 4

Figura 6 – Fiddler capture 1

Figura 7 – Fiddler Capture 2

Analizzando il Token al punto 4 tramite uno strumento in grado di decodificarlo, come ad esempio JWT.io, è possibile analizzare le informazioni di autenticazione che verranno trasmesse all’applicazione.

Figura 8 – JSON Web Token

Come potete osservare l’applicazione riceve semplicemente un JSON Web Token con all’interno tutti i dati necessari a identificare l’utente, sgravandola dal compito di dover implementare una sua logica interna di autenticazione.

Come abilitare la Modern Authentication in Microsoft 365

Per abilitare la Modern Authentication è necessario l’utilizzo di client compatibili con essa:

• Office 2013 (il quale necessita di due chiavi di registro e dal 13 ottobre 2020 non sarà più supportato per l’uso con Microsoft 365 / Office 365)
• Office 2016
  
• Office 2019
  
• Office 365 Apps for Enteprise
  
• Office 365 Apps for Business
  

Così come alcune configurazioni lato tenant Microsoft 365 se è stato creato precedentemente al 1° agosto 2017, tutti i tenant creati successivamente hanno la Modern Authentication abilitata per impostazione predefinita.

Per aggiungere il supporto alla Modern Authentication al tenant andare sull’Admin Center https://admin.microsoft.com/ e portarsi su Settings -> Org settings -> Modern Authentication e spuntare “Turn on modern authentication for Outlook 2013 for Windows and later“, premere quindi su “Save changes”

Figura 9 – Modern Authentication

Questa operazione non ha impatti particolari in quanto aggiunge il supporto alla Modern Authentication senza disabilitare i protocolli legacy. I client che utilizzano ancora i protocolli legacy continueranno a connettersi regolarmente mentre chi è in grado di utilizzare la Modern Authentication noterà il cambiamento nella finestra di login nel client Outlook, che non chiederà più le credenziali come in Figura 3 ma bensì tramite un browser integrato come in Figura 5.

SharePoint Online ha la Modern Authentication già abilitata per impostazione predefinita.

Come disabilitare i protocolli legacy in Microsoft 365

Dopo aver abilitato la Modern Authentication è possibile disabilitare il supporto ai protocolli legacy, questa operazione però va compiuta dopo essersi assicurati che non sono più in uso, pena l’impossibilità di accedere al servizio da parte dei client che ancora li utilizzano.

Per fare ciò collegarsi al pannello di amministrazione di Azure AD https://aad.portal.azure.com e portarsi su Sign-Ins, modificare quindi il filtro predefinito premendo su Add filters e selezionare tutti gli endpoint legacy.

Figura 10 – Legacy Auth Sign-ins

Se non esistono logins effettuati da client legacy si può procedere alla disabilitazione dei protocolli, altrimenti sarà necessario procedere ad una campagna di aggiornamento dei clients (PC ma anche dispositivi mobili). Premendo il tasto Download sarà possibile esportare un file CSV (Comma Separated Values) e maneggiarlo tramite Microsoft Excel.

Per disabilitare i protocolli legacy su Exchange Online sarà sufficiente togliere i segni di spunta dai protocolli che si vuole disabilitare

Figura 11 – Disabilitare Legacy Auth EXO

Mentre per SharePoint Online sarà necessario andare sull’admin center specifico, premere su Policies -> Access Control -> Apps that don’t use modern authentication -> Block access e premere Save

Figura 12 – Modern Authentication SPO

Una volta effettuati questi passi i protocolli legacy sono stati disabilitati con successo.

Conclusioni

La Modern Authentication permette un’esperienza di autenticazione più ricca, sicura e pratica per gli utenti. Un effetto immediatamente tangibile è il ridotto numero di eventi di account lockout e cambi password meno problematici (che fanno più danno che beneficio: Utilizzare Azure AD Identity Protection per rilevare e gestire i rischi legati all’accesso degli utenti) in quanto le applicazioni non eseguono più il caching delle credenziali.

La disabilitazione dei vecchi protocolli di autenticazione, anche senza l’implementazione della Multi Factor Authentication, garantisce un livello di protezione maggiore in quanto gli attacchi ai protocolli legacy sono di gran lunga più comuni e meno onerosi per l’attaccante.

È possibile gestire in maniera granulare le policy di autenticazione tramite diversi strumenti: dalle Authentication Policies per Exchange Online, fino ad arrivare a Conditional Access. I Security Defaults di Azure AD, per i clienti che non hanno a diposizione oppure non vogliono utilizzare Conditional Access, disabilitano i protocolli di autenticazione legacy.