Category Archives: Exchange Online

Exchange Online Protection: ulteriori miglioramenti alla Zero-Hour Auto Purge

Exchange Online Protection: ulteriori miglioramenti alla Zero-Hour Auto Purge

ZAP e Quarantena
ZAP, la zero hour auto purge, è una funzione di Exchange Online Protection(EOP) che, ultimamente è andata incontro ad alcune problematiche (approfondimenti).
Per supportare le aziende, Microsoft sta rilasciando una serie di miglioramenti con l’obiettivo di offrire un controllo più dettagliato ed un allineamento più preciso con gli altri controlli operati.
In poche parole, oltre all’attuale funzione “malware ZAP” che rimuove tutti gli allegati ritenuti non sicuri, ZAP agirà sui messaggi identificati come Spam o Phish mettendoli in quarantena.
Inoltre, Microsoft sta inserendo la possibilità di disabilitare l’elaborazione di phish o spam per ZAP.

Infine, ha annunciato il supporto per lo spostamento dei messaggi ZAP-ed nella quarantena quale parte degli aggiornamenti Phish and spam Zero-hour Auto Purge move to Quarantine annunciati all’interno della roadmap Microsoft 365 – voce 55432.

Exchange Online Protection: ulteriori miglioramenti alla Zero-Hour Auto Purge

Abilitare lo ZAP per Spam e Phish
Mentre l’annuncio della roadmap non ne parla esplicitamente, anche una rapida occhiata alla documentazione fa emergere il fatto che Microsoft stia creando anche dei controlli aggiuntivi che permettano di attivare e disattivare le modalità di rilevamento di spam e/o phish.
Entrambe le nuove modalità saranno abilitate di default e potranno essere controllate tramite i nuovi parametri introdotti per il cmdlet Set-HostedContentFilterPolicy: SpamZapEnabled e PhishZapEnabled.

Il valore per entrambi i nuovi parametri viene attualmente ereditato dal valore del parametro ZapEnabled e rimarrà così fino a febbraio 2020, quando il parametro ZapEnabled sarà disattivato. Di default, i parametri SpamZapEnabled e PhiosZapEnabled saranno abilitati ($true). In futuro, avrete la possibilità di modificare lo stato dei due parametri a $false, disabilitando cosi l’elaborazione dei messaggi di spam e phish da parte di ZAP.

Elaborazione della posta elettronica
In merito alle email, ZAP, si comporterà in questo modo.
a. per i messaggi classificati come malware, rimarrà in vigore l’attuale azione di “remove attachment”
b. per i messaggi identificati come phish o spam, verrà eseguita l’azione configurata nella policy di filtro contenuti.
Per quanto riguarda il punto b, se l’azione è impostata su Quarantine message, Delete message o Redirect message to email address, ZAP sposterà il contenuto in quarantena.
Se, invece, l’azione è impostata su Move message to Junk email folder, verrà applicato il comportamento corrente ed i messaggi saranno spostati nella cartella posta indesiderata.
Infine, se l’azione è impostata su Add X-Header o Prepend subject line with text, o non sono state definite azioni nella policy, allora ZAP non effettuerà alcuna operazione sul messaggio. Vale il medesimo comportamento se è stato disabilitato il processo di spam/phish dai controlli sopra elencati.

Tutti questi miglioramenti introdurranno anche un altro cambiamento nel programma ZAP basato sullo stato di lettura del messaggio.
I messaggi malware continueranno ad essere elaborati indipendentemente dallo stato di lettura. Per i messaggi identificati come phish, l’azione sarà eseguita indipendentemente dallo stato di lettura.
Invece, per quanto riguarda i messaggi contrassegnati come spam, il processo sarà eseguito solo sui messaggi contrassegnati come non letti.


Le informazioni presenti in questo post, sono prese dall’articolo: Exchange Online Protection Improves Zero-Hour Auto Purge (ZAP).

Azure Cloud Shell supporta ora Exchange Online

Oggi siamo felicissimi di annunciarvi che il modulo PowerShell per Exchange Online è disponibile all’interno di Azure Cloud Shell!

Se siete un amministratore di Exchange e non avete mai utilizzato Azure Cloud Shell prima (o non avete idea di cosa sia), allora questo post fa per voi.
Sappiamo perfettamente che non è semplice rimanere sempre aggiornati con tutte le novità di Microsoft, per questo vogliamo mettervi al corrente di questa ingegnosa funzionalità rilasciata di recente.
In sostanza, Azure Cloud Shell è una shell experience autenticata, basata sul browser e ospitata da Microsoft.

Potete utilizzare qualsiasi browser per aprire in maniera sicura un ambiente shell ospitato su Azure, in seguito potete connettervi ad Exchange Online (e ovviamente a Azure) avendo la medesima esperienza di gestione che siete soliti vedere su Exchange Online senza i problemi derivanti dal dover installare componenti o sistemi operativi idonei.

Per iniziare, potete sia raggiungere shell.azure.com che lanciare Cloud Shell direttamente dal portale di Azure cliccando sull’icona di Cloud Shell e selezionando l’esperienza PowerShell.
Potete vedere l’icona di Cloud PowerShell nell’immagine qui sotto circondata da un quadratino azzurro nella barra superiore.
Se invece ci arrivate tramite indirizzo shell.azure.com, dovrete autenticarvi e completare la richiesta di MFA (ci auguriamo che la vostra sottoscrizione abbia abilitato la MFA per tutti gli account).

Azure Cloud Shell supporta ora Exchange Online

A questo punto, tutto quello che dovete fare è eseguire il comando Connect-EXOPSSession.
Dovete utilizzare un account con assegnato il ruolo di Role Based Access Control (RBAC) e con i permessi adeguati.
Microsoft ha abilitato il Single Sign On (SSO) quindi non dovrete fornire altre credenziali.

I comandi Exchange vengono automaticamente traslati all’ambiente Cloud Shell: questo vi permette di effettuare esattamente le stesse attività che fate normalmente utilizzando Exchange Online PowerShell.

Date un’occhiata a questo video proveniente dall’ultima conferenza Microsoft Ignite per scoprire come effettuare questo processo nel modo più semplice possibile.
Tutto quello di cui avete bisogno è un browser!

La sezione seguente risponde alle domande frequenti degli utenti.

Come funziona esattamente?
Quando iniziate una sessione Cloud Shell, siete connessi ad un container Linux eseguito da Microsoft.
Perchè ciò sia possibile, dobbiamo ri-fattorizzare il codice Exchange Online PowerShell perchè lavori correttamente con PowerShell Core.

Una volta che la sessione è aperta, potete usare uno qualsiasi tra gli strumenti disponibili in Azure Cloud Shell e Exchange Online PowerShell.

Quali sono i requisiti?
Per usare Cloud Shell, avete semplicemente bisogno di una sottoscrizione Azure e di un account Azure Storage.
Cloud Shell ha bisogno di uno Storage account in Azure per lo storage temporaneo dell’ambiente di lavoro cmdlet, per qualsiasi import/export che facciate e per salvare i vostri script o gli altri file. Lo storage è persistente per il vostro account quindi ogniqualvolta e dovunque usiate Cloud Shell, tutti i vostri file e script saranno sempre disponibili.

L’unico costo per l’esecuzione di Azure Cloud Shell deriva dall’utilizzo di un account Azure Storage che, solitamente, è molto basso.
I costi di Azure Storage sono basati su un modello di consumo, perciò pagate solo per quanto utilizzate.

Si tratta del set completo dei cmdlet di Exchange?
Sì, è la libreria completa dei cmdlet di Exchange Online. È stato tutto modificato per lavorare all’interno di PowerShell Core. Funziona tutto in modo analogo ad oggi, solo l’accesso è differente.

Microsoft sta deprecando l’attuale Exchange PowerShell module in favore di questo?
Attualmente, Microsoft non ha piani in merito.

Per quanto riguarda RBAC?
RBAC è totalmente rispettato e lavora come fa con Windows PowerShell.

Come importo ed esporto i dati?
Dal portale di Azure o da shell.azure.com, trovate una toolbar contenente l’icona di Upload/Download che può essere utilizzata per spostare i vostri script locali su Cloud Shell e viceversa. Potrete anche fare il drag and drop dei file locali al terminale e saranno caricati automaticamente al Cloud Shell.

I file che sono salvati sotto il clouddrive all’interno di Cloud Shell, saranno disponibili da ovunque possiate raggiungere il vostro storage account Azure come, ad esempio, Azure Storage Explorer.

Azure Cloud Shell supporta ora Exchange Online

Come mantengo Cloud Shell aggiornato?
Non è un vostro compito, Microsoft lo fa per voi.
È questo il bello di questo setup: è sempre aggiornato, sicuro ed accessibile da dovunque possiate raggiungerlo con un browser.

Ci sono altri modi per accedere a Cloud Shell?
Azure Cloud Shell è disponibile dal Portale di Azure, da shell.azure.com, Azure Mobile App, Azure Extension in Visual Studio Code, dal pulsante “Try it” all’interno di Microsoft Docs e da Microsoft Learn.

Quali altri vincoli vi sono?
L’unico, se vogliamo considerarlo tale, è il timeout: per evitare di avere sessioni costantemente in esecuzione senza senso, Microsoft ha creato un timeout delle sessioni con cui non vi è un utilizzo interattivo. In sostanza, se non toccate la macchina per più di 20 minuti, viene richiamata la sessione.
Vi anticipiamo che l’attuale timeout dovrebbe funzionare per la maggior parte degli scenari di gestione ad hoc ma se volete eseguire script a lungo termine, probabilmente Cloud Shell non è lo strumento migliore.

A questo link una guida Quickstart.


Le informazioni presenti in questo post, sono prese dall’articolo Azure Cloud Shell Now Supports Exchange Online.

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.

Conservare una copia delle email inviate dalle shared mailbox di Exchange online

Le shared mailbox rappresentano un utilissimo strumento che può essere utilizzato per una varietà di scenari all’interno del tuo ambiente aziendale.

Funzionalità
Le email possono essere inviate direttamente da una mailbox condivisa o per conto di uno dei suoi membri, ipotizzando che siano stati distribuiti gli adeguati permessi.
La funzionalità in questione è progettata per conservare una copia dell’email inviata dalla shared mailbox all’interno della cartella Posta Inviata della casella di posta condivisa. Lo stesso comportamento vogliamo che avvenga per le email inviate “per conto di” della shared mailbox.

Attenzione: se l’utente ha utilizzato la funzionalità di Outlook 2013 per modificare la cartella in cui vengono salvate le email inviate, i messaggi verranno copiati in quella cartella e non nella Posta Inviata. Gli utenti possono riconfigurare quest’impostazione, cliccando su Opzioni – Posta – Salva una copia dei messaggi nella cartella Posta Inviata.

Come abilitarla
Entriamo adesso nel portale di Office 365 e vediamo che opzioni abbiamo per le shared mailboxes su Exchange online.
Dopo aver effettuato il login al nostro portale, rechiamoci sui Gruppi ed espandiamo il menù:

Conservare una copia delle email inviate dalle shared mailbox di Exchange online

Scegliamo ora la mailbox su cui abilitare la funzionalità di conservazione della copia della posta inviata:

Conservare una copia delle email inviate dalle shared mailbox di Exchange online

In questo modo abbiamo abilitato la funzionalità per la cartella condivisa desiderata.
Come indicato nella seguente immagine, vi sono due pulsanti all’interno della schermata: uno per l’invio come cartella condivisa e l’altro per l’invio per conto della cartella condivisa.
Abilitando le due opzioni e cliccando Save, sulla riga corrispondente del pannello informativo la dicitura passerà da “Not copied to mailbox” a “Copied to mailbox”.

Conservare una copia delle email inviate dalle shared mailbox di Exchange online

Effettuare la verifica con PowerShell
Dopo aver attivato le opzioni desiderate per la shared mailbox desiderata, possiamo connetterla ad exchange online remote PowerShell e verificarne le impostazioni.

Se eseguiamo il seguente comando:
Get-Mailbox -Identity sharedmailbox@contoso.com | FL

Usciranno due questi due attributi, appena modificati come da immagine precedente:
MessageCopyForSentAsEnabled : True

MessageCopyForSendOnBehalfEnabled : True

Ovviamente, possiamo anche impostare questi attributi per le shared mailbox via PowerShell.
Il comando per eseguire quest’operazione è il seguente:
Set-Mailbox -Identity sharedmailbox@contoso.com -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

Se invece vogliamo abilitare l’opzione per tutte le nostre mailbox condivise, possiamo farlo eseguendo il seguente comando:
Get-Mailbox -RecipientTypeDetails shared | Where-Object{$_.messagecopyforsentasenabled -eq “”} | Set-Mailbox -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true


Le informazioni presenti in questo post, sono prese dall’articolo: Enabling Sent Items Copy features with Exchange online for shared mailboxes.

Assegnazione di un contatto di tipo Guest Mail User ad una Distribution List

Oggi parliamo di una problematica che, probabilmente, è capitata a molti di voi e vedremo come risolverla.

Mettiamo il caso che dobbiate aggiungere un contatto di tipo Guest User ad una Distribution List.
Vi accorgerete che, dall’interfaccia amministrativa di Office 365, non è possibile farlo in quanto, quel contatto, non è presente all’interno dell’elenco di selezione che vi si presenta nel momento in cui dovete aggiungere utenti al gruppo.

Assegnazione di un contatto di tipo Guest Mail User ad una Distribution List

Per risolvere il problema, è sufficiente utilizzare un semplice comando Powershell:

Add-DistributionGroupMember -Identity “nomelista” -Member “utenteguest”

Assegnazione di un contatto di tipo Guest Mail User ad una Distribution List

Con questo unico comando, risolvete il problema e potrete aggiungere alle vostre liste di distribuzione anche utenti di tipo guest.