Category Archives: Azure Active Directory

Annunciata la public preview del supporto di Azure AD per FIDO2: verso un sign in senza password

Avevamo parlato dell’argomento nel nostro post Windows Hello FIDO2: sempre più vicini a un mondo senza password.
Oggi siamo felicissimi di annunciarvi che, grazie alla public preview del supporto di FIDO2 security keys in Azure Active Directory ci avviciniamo sempre più a scenari aziendali in cui le password non sono più richieste nè necessarie.
Sono stati molti i team di Microsoft coinvolti in questo progetto.
L’obiettivo? Far sì che la tecnologia di FIDO2 potesse fornire accesso scorrevole, sicuro e senza password a tutte le app e i servizi connessi ad Azure AD.

Inoltre, sono state attivate tutta una serie di funzionalità di amministrazione nel portale di Azure che vi permettono di gestire i fattori di autenticazione per utenti e gruppi della vostra azienda.
In questo primo release, potete utilizzarle per gestire un rollout organizzato dell’autenticazione senza password utilizzando le security key di FIDO2 e/o l’applicazione Microsoft Authenticator.
Andando avanti, vedrete la possibilità di gestire tutti i tradizionali fattori di autenticazione (Multi-Factor Authentication (MFA), OATH Token, sign in con numero di telefono, ecc.).
L’obiettivo è quello di abilitarvi all’utilizzo di questo strumento per gestire tutti i fattori di autenticazione.

Senza password non significa meno sicuro
Ogni giorno sempre più aziende spostano le loro infrastrutture sul cloud e utilizzano le applicazioni che si trovano “sulla nuvola”.
Per farlo in maniera coscienziosa, devono sapere che i dati e i servizi archiviati nel cloud sono al sicuro.
Purtroppo, le password non rappresentano più un meccanismo di sicurezza efficace. Gli industry analysts, infatti, riportano che l’81% dei cyberattacchi che vanno a buon fine iniziano da username e password compromesse. Inoltre, la tradizionale MFA, nonostante sia molto efficace, può essere di difficile utilizzo e non viene ancora molto usata.

La missione di Microsoft è quella di fornire ai propri clienti metodi di autenticazione che siano sicuri e di facile utilizzo di modo che gli utenti possano tranquillamente accedere alle informazioni senza preoccuparsi del fatto che qualche hacker prenda possesso del loro account.

Ed è in questo scenario che entra in gioco la passwordless authentication.
Microsoft crede fermamente che aiuterà le aziende a ridurre in maniera significativa e permanente il rischio di account compromessi.

Annunciata la public preview del supporto di Azure AD per FIDO2: verso un sign in senza password

Ora, tutti gli utenti di Azure AD possono autenticarsi senza password utilizzando FIDO2 security key, l’app Microsoft Authenticator, o Windows Hello. Questi potenti fattori di autenticazione sono basati sugli stessi standard e protocolli public key/private key, protetti da fattori biometrici (impronta o riconoscimento facciale o da un PIN. Gli utenti utilizzano un fattore biometrico o un PIN per sbloccare la chiave privata archiviata in maniera sicura sul dispositivo.
La chiave è poi utilizzata per comprendere chi sono utente e dispositivo in relazione a quel determinato servizio.

Annunciata la public preview del supporto di Azure AD per FIDO2: verso un sign in senza password

Da dove iniziare
Per aiutarvi a prendere confidenza ed iniziare il vostro percorso verso un mondo senza password, Microsoft ha rilasciato una serie di funzionalità in versione public preview.
Queste nuove feature includono:
una nuova opzione relativa ai metodi di autenticazione all’interno del portale di amministrazione di Azure AD che vi permette di assegnare ad utenti e gruppi credenziali senza password utilizzando le security key di FIDO2 e il sign-in senza password utilizzando il Microsoft Authenticator.

Annunciata la public preview del supporto di Azure AD per FIDO2: verso un sign in senza password

– funzionalità aggiornate nel Registration portal per i vostri utenti che permettono di creare e gestire le FIDO2 security keys.

Annunciata la public preview del supporto di Azure AD per FIDO2: verso un sign in senza password

– Possibilità di utilizzare le FIDO2 security key per autenticarsi sui dispositivi Windows 10 collegati ad Azure AD ed aggiornati all’ultima versione dei browser Edge e Firefox.

Annunciata la public preview del supporto di Azure AD per FIDO2: verso un sign in senza password

Hardware FIDO2
Microsoft ha lavorato assieme ad alcuni partner di hardware quali Feitian Technologies, HID Global e Yubico per assicurarsi di avere una serie di form factor a disposizione per il lancio, incluse le chiavi che si connettono via USB e protocolli NFC.

Maggiori dettagli sulle partnership.

Verificate che tutte le chiavi di sicurezza FIDO2 che state prendendo in considerazione per la vostra azienda siano conformi alle ulteriori opzioni richieste per essere compatibili con l’implementazione di Microsoft.

Annunciata la public preview del supporto di Azure AD per FIDO2: verso un sign in senza password

La strategia passwordless di Microsoft
La strategia di Microsoft consiste in un approccio a quattro step:
– implementazione dell’offerta alternativa,
– riduzione dell’area coperta da password,
– transizione verso un deployment senza password,
– eliminazione delle password.

Annunciata la public preview del supporto di Azure AD per FIDO2: verso un sign in senza password

Questo è un passo importantissimo verso la realizzazione di scenari aziendali in cui gli utenti non hanno bisogno di password.
Oltretutto, il lavoro di ingegneria svolto per fornire una gestione dei metodi di autenticazione agli amministratori ed il controllo della registrazione dell’utente, permetterà a Microsoft di muoversi ancora più velocemente verso un miglioramento dell’esperienza di gestione delle credenziali assieme alla possibilità di portare nuove funzionalità e credenziali online in modo più semplice.
Inoltre, Microsoft è già al lavoro con il team Windows security engineering per far sì che l’autenticazione FIDO2 funzioni anche sui dispositivi hybrid-joined.

Potete rilasciare i vostri feedback in merito a tutte queste funzionalità, a questo link.

Le informazioni presenti in questo post, sono prese dall’articolo: Announcing the public preview of Azure AD support for FIDO2-based passwordless sign-in.

I criteri di denominazione dei gruppi di Office 365 sono ora configurabili all’interno del portale di Azure Active Directory

Utilizzare PowerShell o il portale per configurare i criteri di denominazione dei gruppi di Office 365

Lo scorso Marzo, in un nostro post, avevamo annunciato la General Availability del criterio di denominazione dei Gruppi di Office 365.

Questa proprietà, permette ai tenant di applicare una naming policy per i gruppi di Office 365 creati dagli utenti tramite applicazioni di tipo group-enabled quali Teams, Outlook, Planner, Stream e Yammer.
Il criterio, invece, non si applica ai gruppi creati dagli amministratori.

Sin dal 2016, gli amministratori hanno configurato la naming policy attraverso PowerShell.
Ora, è stata rilasciata una preview che vi permette di effettuare le stesse operazioni dal portale di Azure Active Directory (Immagine 1).
Recatevi nella sezione dei gruppi del portale e troverete elencate le naming policy all’interno delle Impostazioni.

I criteri di denominazione dei gruppi di Office 365 sono ora configurabili all'interno del portale di Azure Active Directory
Immagine 1: configurare Office 365 Groups Naming Policy all’interno del portale AAD

La configurazione delle impostazioni delle policy tramite un’interfaccia grafica è più semplice rispetto a PowerShell, in particolar modo considerato che devono essere effettuati dei passaggi alquanto complicati per alterare i policy object di Azure Active Directory.
Oltre ad impostare variabili di prefissi e suffissi per aggiungere i nomi forniti dagli utenti, il portale vi permette anche di gestire le parole bloccate.
Si tratta di parole che non volete che gli utenti utilizzino nei nomi dei gruppi. Alcune sono parole pratiche come Payroll e CEO, altri sono termini offensivi.

I criteri non sono retrospettivi
Tenete presente che la Groups Naming Policy si applica solo ai nuovi gruppi e non agli standard di denominazione dei vecchi.
Se volete utilizzare il nuovo standard con i vecchi gruppi, dovrete utilizzare PowerShell.

Funzionalità Premium di AAD
L’utilizzo dei criteri di denominazione dei gruppi di Office 365 è una funzionalità premium di Azure Active Directory che richiede agli utenti il possesso di una licenza Azure Active Directory Premium P1.


Le informazioni presenti in questo post, sono prese dall’articolo: Office 365 Groups Naming Policy Now Configurable in Azure Active Directory Portal.

Azure AD Password Protection ora disponibile

Molti di voi avranno sicuramente utilizzato la versione di Azure AD Password Protection in preview.
Azure AD Password Protection vi permette di eliminare facilmente le password intuitive e di customizzare le impostazioni di blocco per il vostro ambiente.
Utilizzandolo, potete significativamente abbassare il rischio di compromettere la sicurezza dell’azienda a causa di un attacco password spray.
Ancor più interessante: è disponibile sia per ambienti cloud che ibridi.
Come sempre, questo risultato è frutto dell’impegno e lavoro di Microsoft unito ai consigli e feedback forniti dagli utenti che hanno testato la preview.

Oggi siamo felici di annunciarvi che la funzionalità ha da poco raggiunto la general availability!

Per aiutare gli utenti ad evitare di scegliere password deboli e vulnerabili, Microsoft ha aggiornato l’algoritmo delle password bannate. Utilizzanto la lista globale delle banned password che Microsoft aggiorna in continuazione e la custom list definita dalle singole aziende, Azure AD Password Protection è ora in grado di bloccare un vasto range di passoword facilmente indovinabili.

Leggete la documentazione dettagliata per saperne di più su come viene valutata la sicurezza di una password e su come Azure AD Password Protection può aiutarvi a bloccare la scelta di password deboli all’interno della vostra organizzazione.

Iniziamo
Azure AD Password Protection può essere facilmente configurato dal portale di Azure AD.
Prima di tutto, loggatevi all’interno del portale di Azure con un account global administrator.
In seguito, recatevi in Azure Active Directory ed poi nella sezione Authentication methods dove vedrete l’opzione Password protection.

Azure AD Password Protection ora disponibile

Configurare Azure AD Password Protection
1. Customizzate il vostro lockout threshold (numero di errori prima del blocco) e la duration (quanto a lungo duri il blocco);
2. Inserite la stringa di password bannate decise dalla vostra azienda nella sezione predisposta (una stringa per riga) ed attivate l’enforcement della vostra lista custom. Raccomandiamo caldamente di utilizzare quest’opzione alle aziende che hanno molteplici brand e prodotti con cui gli utenti si identificano.
3. Estendete la banned password protection al vostro Active Directory abilitando Password Protection for Windows Server Active Directory. Iniziate con l’audit mode che esegue la Password Protection nella modalità “what if”. Una volta che siete pronti per implementare Password Protection, passate alla modalità Enforced per iniziare a proteggere gli utenti evitando di utilizzare Azure AD Password Protection for Windows Server Active Directory.

Attenzione: tutti gli utenti sincronizzati devono avere una licenza per poter utilizzare Azure AD Password Protection for Windows Server Active Directory.

Proteggere l’ambiente on-premises
Per utilizzare Azure AD Password Protection su Windows Server Active Directory, scaricate l’agent dal download center e seguite le istruzioni all’interno della guida per il deployment di Password Protection.

Una volta che il vostro global admin, ha abilitato Password Protection for Windows Server Active Directory, il security administrators potrà prenderlo e completare la registrazione sia per il proxy agent che per le foreste di Active Directory. Sia il domain controller dell’agent che il proxy agent supportano l’installazione invisibile che può essere sfruttata utilizzando diversi meccanismi di deployment come il SCCM.

Attenzione: i clienti precedenti DEVONO immediatamente aggiornare gli agent all’ultima versione (1.2.125.0 o successive). L’agent corrente, smetterà di funzionare a partire dal 01 Luglio 2019.

Eliminare la Basic Auth per Exchange Online grazie alle Condition policy di AAD

Ridurre gli account compromessi di Exchange Online
Lo scorso Ottobre, Microsoft ha introdotto la possibilità, per i tenant di Office 365, di disabilitare la basic authentication per Exchange online utilizzando il protocollo di autenticazione delle policy. Un tweet recente di Alex Weinart, Group program manager del team di Azure Active Directory ha dichiarato che la disabilitazione della basic auth riduce la percentuale di account compromessi fino al 67%.

Eliminare la Basic Auth per Exchange Online grazie alle Condition policy di AAD

Questo argomento, ci riporta un po’ al post pubblicato qualche giorno fa: Azure AD Mailbag: scoprire e bloccare l’autenticazione legacy in cui abbiamo visto come la basic authentication non sia proprio l’ideale, soprattutto per i tenant che supportano ancora protocolli datati quali IMAP4 and POP3.

Perchè si usano ancora i vecchi client email?
Non abbiamo una risposta a questo quesito.
Sia l’IMAP4 che il POP3 sono nati in concomitanza con l’arrivo delle email, quando internet era un posto molto più sicuro e gli aggressori non utilizzavano tecnologie quali attacchi brute-force e password spray.

Non ci sono grandi giri di parole da fare: ad oggi sono disponibili email client più moderni e sicuri.
I client che supportano la modern authentication includono OWA per i browser e Outlook versione mobile per Android e iOS. Le persone che utilizzano Outlook per Windows dovrebbero essere incoraggiate ad utilizzare la modern authentication. Oltre alle motivazioni personali, non esiste una buona ragione oggettiva che supporti l’utilizzo di client datati e non sicuri. Il punto fondamentale è che se decidete di indirizzare i vostri utenti verso un client più sicuro, potrete disabilitare completamente i protocolli quali IMAP4 e POP3 e dare man forte alla difesa del vostro tenant.

Exchange Web Services
Nonostante possa utilizzare anche la basic auth, Exchange Web Services(EWS), si trova in una categoria differente rispetto ad IMAP4 d POP3. EWS è utilizzato dal client Outlook for Mac e dai prodotti di back-up e migrazione utili a far fluire i dati di Exchange Online dalle mailbox (backup) o importare le informazioni nelle mailbox (migrazione).
È anche possibile utilizzare EWS da prodotti di terze parti. In sostanza, è difficile eliminare EWS in tempi brevi.

Comprendere e gestire i protocolli di connessione
Il post citato prima, sottolinea due punti fondamentali.
– Prima di tutto, dovreste capire quale protocollo è in un utilizzo per connettere le caselle di posta di Exchange Online al vostro tenant. Se non sapete chi utilizza quei protocolli, non sarete in grado di gestire il controllo dei protocolli utilizzando la basic auth.
– Seconda cosa, partendo dal presupposto che tutti gli account utenti importanti dovrebbero essere protetti dalla MFA, le policy di conditional access di Azure Active Directory, sono un modo molto flessibile e conveniente per limitare le connessioni di tipo basic auth il più possibile. Chiaramente, dovete essere disposti a pagare per una licenza Azure AD Premium (che abilita anche altre utili funzionalità quali le Office 365 group expiry e le naming policies).
Come abbiamo sottolineato nel post precedente, lo scorso anno Microsoft ha aggiunto la possibilità di bloccare l’autenticazione legacy nel conditional access.

Eliminare la Basic Auth per Exchange Online grazie alle Condition policy di AAD

Considerate le cyber-minacce che oggigiorno ci troviamo ad affrontare ed il numero di attacchi che tentano di penetrare nei tenant Office 365, dovreste quanto meno porvi la domanda: devo implementare la policy di conditional access che blocchi la basic auth (magari ad un determinato gruppo di utenti o piattaforme client) per eliminare o ridurre il rischio rappresentato dalla presenza di una basic authentication nel nostro tenant? Se volete il nostro parere, Sì, è la cosa giusta da fare!


Le informazioni presenti in questo post, sono prese dall’articolo: Eliminating Basic Auth for Exchange Online with AAD Condition Policies.

Azure AD Mailbag: scoprire e bloccare l’autenticazione legacy

Molte volte ci troviamo nella situazione in cui dobbiamo aiutare i nostri clienti ad evitare attacchi alle loro password e la legacy authentication è un componente chiave dell’argomento. Questo perchè questi protocolli e client sono comunemente utilizzati per effettuare attacchi di tipo brute-force o password spray.
In questo post, andremo a vedere quali sono le sfide dell’autenticazione legacy e come utilizzare Azure AD e Microsoft Exchange Online per avere un miglior controllo dell’accesso.
Affronteremo questi argomenti con un approccio di tipo domanda e risposta.

1. Cos’è l’autenticazione legacy e quali sono i problemi che si riscontrano?
Parlando in linea generica l’autenticazione legacy si riferisce ai protocolli che utilizzano un’autenticazione base (Basic Auth).
Si tratta cioè di quei protocolli che richiedono un singolo fattore di autenticazione di username e password e tipicamente non possono applicare un secondo fattore quale componente del flusso di autenticazione.
Al lato opposto, troviamo la modern authentication (Modern Auth) che può invece richiedere un secondo fattore di autenticazione. In questo caso, solitamente l’app o il servizio in questione mostrano un frame del browser che permette all’utente di fornire quanto richiesto come secondo fattore.
Può trattarsi di un codice temporaneo, l’approvazione di una notifica push sul telefono o la risposta ad una chiamata in arrivo.

Altra differenza fondamentale è che in un percorso di autenticazione legacy, l’app client o servizio raccoglie le credenziali ed in seguito le convalida.
Essenzialmente, l’app o servizio “ottiene la fiducia” per gestire le credenziali in maniera sicura.
Nella modern authentication, le credenziali sono sempre es solo fornite ad un’autorità di fiducia (ad esempio un redirect ad Azure AD o AD Federation Services) e, dopo l’autenticazione, viene rilasciato un token per l’applicazione o un servizio che agisce per conto dell’utente.

Esempi di protocollo che usano l’autenticazione legacy sono POP3, IMAP4, e SMTP.
Ci sono altri protocolli che utilizzano Basic Auth e Modern Auth quali MAPI e EWS.

Quindi, dove sta il problema?

La single factor authentication oggigiorno non è sufficiente per rimanere al sicuro!
Le password sono deboli perchè semplici da indovinare, le persone non impiegano molto sforzo nella scelta di combinazioni più complicate e tendono a fornirle agli hacker attraverso gli attacchi (ad esempio il phishing). Una delle cose più semplici da fare per proteggerci dalle minacce alle password è implementare la multi-factor authentication (MFA).
In questo modo, anche se un aggressore dovesse impossessarsi della password di un utente, questa da sola non basterà per autenticarsi con successo ed avere accesso a dati e risorse.

I protocolli che utilizzano la legacy authentication, in particolare quelli utilizzati per recuperare email quali POP3, IMAP e EWS sono modi molto semplici per attuare attacchi di tipo brute-force e password spray perchè se una delle combinazioni di username e password tentate è corretta, l’aggressore avrà accesso alle email dell’utente.

2. Quindi cosa facciamo con questi protocolli?
La raccomandazione è di bloccare l’autenticazione legacy, o se avete dei casi particolari in azienda per cui dovete permetterne l’utilizzo, applicate alcuni controlli che ne permettano per specifici utenti e location.
Prima di farlo, cercate di capire quale sia il loro utilizzo nell’organizzazione.

Lo scorso anno, Microsoft ha fatto alcuni miglioramenti ai log di sign-in in Azure AD: ora ricevete le attività più velocemente e recuperate maggiori informazioni per ognievent.
Parte di questa informazione è la Client App property, dove venite informati sul procotollo/app utilizzati per effettuare il sign-in.

Azure AD Mailbag: scoprire e bloccare l'autenticazione legacy

La prima cosa che dovete fare è impegnare del tempo ad analizzare i log per comprendere l’utilizzo di questi client e dei protocolli in tutta l’azienda.
Per farlo, potreste scaricare i log per suddividerli ed analizzarli con Microsoft Excel o, ancora meglio, inserirli all’interno del vostro sistema di security information and event management (SIEM) che vi fornisce sicuramente funzionalità di analisi dati e alert più potenti.
Per capire come immettere i log nel SIEM, date un’occhiata a questo post: Azure AD Mailbag: Return Of The Mailbag with Azure AD Logs.
Una volta compreso chi sta usando cosa, potreste aver bisogno di aggiornare i client alle versioni che supportano la Modern Auth o convincere gli utenti a smettere di utilizzare protocolli come IMAP4 ed aggiornarsi a tecnologie più attuali.

3. Ok, siamo pronti ad imporre maggior controllo. Come facciamo?
Fino all’anno scorso, vi erano due modi di bloccare l’autenticazione legacy in Azure AD.

In ambienti federate (che utilizzano ad esempio AD FS), potreste utilizzare regole specifiche che permettano determinati protocolli e neghino l’accesso ai rimanenti.
Il tutto si complica quando dovete iniziare ad aggiungere condizioni ed eccezioni.

Implementare la MFA per utente, costringerà gli utenti ad utilizzare le password delle app per i protocolli di legacy authentication. In ogni caso, se non ne permettete l’utilizzo, bloccate
in toto questi protocolli. La cattiva notizia qui è che non potete applicare soltanto alcune condizioni: o tutte o nessuna. Inoltre, applicare la MFA per utente, non è il metodo migliore da utilizzare al giorno d’oggi: il conditional access vi dà maggiore flessibilità.
Lo scorso anno, Microsoft ha aggiunto la possibilità di bloccare l’autenticazione legacy nel conditional access e per questo vi raccomandiamo di iniziare da qui.
Con il conditional access, guadagnerete la flessibilità necessaria a supportare gli utenti o le app che hanno ancora bisogno di utilizzare i protocolli con la legacy authentication e bloccarne gli altri.

Ad esempio, se avete un’app che supporta un processo di business che utilizza l’IMAP per recuperare le email da una casella di posta di Exchange Online, potete utilizzare il conditional access per permettere quel flow soltanto per quello specifico utente se la sorgente IP è uno dei vostri IP e bloccare qualsiasi altro tentativo.
Vi rimandiamo all’articolo Block legacy authentication to Azure AD with conditional access per saperne di più.

Azure AD Mailbag: scoprire e bloccare l'autenticazione legacy

Quello che ha creato un po’ di confusione è stato che le policy di conditional access non includono la legacy authentication dei client di default.
Questo significa che se avete una policy di conditional access che applica l’MFA per tutti gli utenti e le app cloud, non verrà bloccata l’autenticazione legacy dei client (o di “Other clients” considerato che la CA UI si riferisce a quelli). La legacy authentication dei client può ancora operare l’autenticazione soltanto con username e password. Per bloccare, create semplicemente una nuova policy.

Un altro modo per bloccare l’autenticazione legacy è impedendola dal lato service-side o resource-side (vs piattaforma di autentificazione).
Raccomandiamo quest’approccio se combinato con le policy di Azure AD Conditional Access. Ad esempio, in MS Exchange Online, potete disabilitare il POP3 o l’IMAP per l’utente. Il problema di questa disabilitazione è che non volete bloccare i protocolli che possono effettuare sia la legacy che la modern authentication (come EWS, MAPI) perchè vi servono.
Per risolvere l’inghippo, Exchange Online ha rilasciato una nuova funzionalità chiamata authentication policies che può essere utilizzata per bloccare le autenticazioni legacy per protocollo dello specifico utente o per l’intera organizzazione.
Ci piace questa caratteristica perchè, con questo approccio, state bloccando i tentativi di utilizzo del protocollo a monte, il che significa che gli aggressori non tenteranno nemmeno di indovinare le password. La connessione al protocollo è negata ancor prima del controllo delle credenziali su Azure AD o gli AD Federation Services quindi l’esecuzione viene fatta pre-autenticazione.
Le policy di conditional access sono invece valutate dopo che l’utente (o l’aggressore) ha effettuato l’autenticazione quindi l’enforcement è eseguito post-autenticazione.

Per maggiori informazioni: Disable Basic authentication in Exchange Online.


Le informazioni presenti in questo post, sono prese dall’articolo: Azure AD Mailbag: Discovering and blocking legacy authentication.