Category Archives: Azure Active Directory

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.

Connessione di Azure Active Directory con molteplici foreste: “the specified domain does not exist or cannot be contacted”

Configurare una soluzione di sincronizzazione multi foresta per un unico tenant di Office 365, è un’operazione abbastanza semplice ma vi sono alcuni trucchetti da tenere presenti:

1. La risoluzione del DNS è critica, aggiungendo alcune voci del file host non risolverete nulla. Utilizzate un forwarder condizionale ad un DC per ogni foresta;
2. Assicuratevi che le porte firewall appropriate siano aperte.
Maggiori info qui: Porte e protocolli necessari;
3. MOLTO IMPORTANTE Assicuratevi di scrivere il vostro login nel formato NetBIOS ed includete il suffisso. Ad esempio, LIEBEN.NU\Admin, se utilizzate LIEBEN\Admin non funzionerà.

Vi raccomandiamo di seguire alla lettera questi punti fondamentali.
Nel caso in cui non lo facciate, probabilmente, vi si presenterà il seguente errore.

[ERROR] Caught exception while validating the domain credentials and retrieving domain FQDN of the specified user XXXX.XXX\Admin.
Exception Data (Raw): System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException: The specified domain does not exist or cannot be contacted.
at System.DirectoryServices.ActiveDirectory.Domain.GetDomain(DirectoryContext context)
at Microsoft.Online.Deployment.Framework.Providers.ActiveDirectoryProvider.ValidateUserCredentials(String domainName, String username, SecureString password, String& domainFqdn)
at Microsoft.Online.Deployment.OneADWizard.UI.WizardPages.ConfigSyncDirectoriesPageViewModel.ValidateADDirectoryConnection(DirectoryConnectionViewModel connection)