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.