blog.icewolf.ch

Let's talk about IT!
posts - 1753, comments - 295, trackbacks - 0

My Links

Archives

Post Categories

icewolf

Monday, April 5, 2021

Be careful with the EwsAllowList / EwsBlockList in Exchange OrganizationConfig

Hallo zusammen,

Vor ein paar Wochen habe ich ein bisschen mit der EwsAllowList / EwsBlockList in der Exchange OrganizationConfig herumgespielt.

Setzt man einen Wert (User Agent) in die EwsBlockList, so ist alles erlaubt, ausser dieser UserAgent. Setzt man einen Wert (User Agent) in die EwsAllowList, so ist nur dieser UserAgent erlaubt, alles andere ist nicht erlaubt.

Set-OrganizationConfig

https://docs.microsoft.com/en-us/powershell/module/exchange/set-organizationconfig?view=exchange-ps

Get-OrganizationConfig | fl *ews*

Der Anbieter eines 3rd Party Kalender Displays für Meeting Rooms hat das ganz gut zusammengefasst.

How to Limit Third-Party Application Access to Exchange & Office 365 Services via EwsApplicationAccessPolicy, EnforceAllowList, and EnforceBlockList

https://blog.meetingroom365.com/how-to-limit-third-party-application-access-to-exchange-office-365-services-via-ewsapplicationaccesspolicy-enforceallowlist-and-enforceblocklist/

Set-OrganizationConfig -EwsAllowList @{add='MeetingRoom365/*'}

Get-OrganizationConfig | fl *ews*

Danach habe ich mich versucht über ein PowerShell Script und der EWS Managed API mit meiner Mailbox zu verbinden.

Hinweis: Dafür muss Basic Auth in der Conditional Access Policy für diesen User zugelassen sein und die Authentication Policy muss dies ebenfalls für diese Mailbox erlauben

In den Azure AD Sign-ins findet man zwar die Anmeldung, aber nicht, dass es wegen der EwsAllowList nicht geklappt hat. Aber man findet dort den UserAgent: ExchangeServicesClient/15.00.0913.015

Also tragen wir den mal ein

Set-OrganizationConfig -EwsAllowList @{add='ExchangeServicesClient/*'}

Get-OrganizationConfig | fl *ews*

Nun klappt die Abfrage der Folder mit dem PowerShell und der EWS Managed API.

Allerdings habe ich dann festgestellt, dass beim Teams im WebBrowser der Kalender nicht mehr funktioniert.

Und auch auf dem Teams Desktop Client war der Kalender verschwunden.

Dann bin ich auf folgenden Artikel gestossen, da sind mehrere UserAgents angegeben, welche freigeschaltet werden müssen.

 

Troubleshoot Microsoft Teams and Exchange Server interaction issues

https://docs.microsoft.com/en-us/microsoftteams/troubleshoot/known-issues/teams-exchange-interaction-issue

Set-OrganizationConfig -EwsAllowList @{Add="MicrosoftNinja/*","*Teams/*","SkypeSpaces/*"}
Set-OrganizationConfig -EwsAllowList @{Add="*SchedulingService*"}
Set-OrganizationConfig -EwsAllowList @{Add="*Microsoft.Skype.Presence.App/*"}

Leider sieht man in den AzureAD Sign-Ins unter dem Filter "Exchange Web Services" nur Legacy Authentications. Nicht aber Clients mit Modern Authentication.

Einige alte Office Versionen melden sich ja auch noch mit Legacy Auth an und auf die Exchange Web Services greifen alle Outlook Versionen zu.

Folglich müssen da ganz viele UserAgents freigeschaltet werden.

#Change

Get-OrganizationConfig | fl *ews*

Set-OrganizationConfig -EwsAllowList @{Add="MicrosoftNinja/*"}

Set-OrganizationConfig -EwsAllowList @{Add="*Teams/*"}

Set-OrganizationConfig -EwsAllowList @{Add="*SchedulingService*"}

Set-OrganizationConfig -EwsAllowList @{Add="SkypeSpaces/*"}

Set-OrganizationConfig -EwsAllowList @{Add="UCCAPI/*"}

Set-OrganizationConfig -EwsAllowList @{Add="OC/*"}

Set-OrganizationConfig -EwsAllowList @{Add="*Microsoft.Skype.Presence.App/*"}

Set-OrganizationConfig -EwsAllowList @{Add="Outlook-Android/*"}

Set-OrganizationConfig -EwsAllowList @{Add="Outlook-iOS/*"}

Set-OrganizationConfig -EwsAllowList @{Add="Microsoft Office/*"}

Set-OrganizationConfig -EwsAllowList @{Add="Microsoft+Office/*"}

Set-OrganizationConfig -EwsAllowList @{Add='ExchangeServicesClient/*'}

#Set-OrganizationConfig -EwsAllowList @{Remove='ExchangeServicesClient/*'}

Set-OrganizationConfig -EwsAllowOutlook $true

Fazit:

Es gibt zwar eine Möglichkeit hier EWS Applikationen anhand von UserAgents zuzulassen oder zu blockieren. Das Troubleshooting dazu ist aber sehr schwierig bis unmöglich.

Ausserdem habe ich einige Applikationen gesehen, welche wie ich das EWS Managed API mit dem UserAgent "ExchangeServicesClient/*" benutzen. Da wird es schwierig, einzelne Applikationen zu blockieren, wenn sie keinen eindeutigen UserAgent haben.

Aus diesen Gründen würde ich hier eher empfehlen die Finger davon zu lassen und auf MFA und Azure AD Application Authentication zu setzen.

Grüsse
Andres Bohren

posted @ Tuesday, April 6, 2021 11:48 PM | Filed Under [ Exchange O365 ]

Sender Rewriting Scheme (SRS) in Exchange Online

Hallo zusammen,

Kürzlich habe ich mich mit dem Sender Rewriting Scheme (SRS) auseinandergesetzt. In diesem Artikel beschreibe ich meine Erkenntnisse.

Bisschen schade ist, dass Microsoft vom "P1 From" spricht. Erklärt dann aber, dass es sich um das Envelope From handelt.

Sender Rewriting Scheme (SRS) in Office 365
https://docs.microsoft.com/en-us/office365/troubleshoot/antispam/sender-rewriting-scheme

Sender Rewriting Scheme (SRS) coming to Office 365 (06-15-2018)
https://techcommunity.microsoft.com/t5/exchange-team-blog/sender-rewriting-scheme-srs-coming-to-office-365/bc-p/2237609#M30033

Sender Rewriting Scheme
https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme

Grundlagen

Emails sind wie bei einem Brief aufgebaut. Es gibt den Umschlag mit Absender und Empfänger. Das ist das, was der Postbote oder eben der Mailserver für die Zustellung benutzt. Gegenüber dieser Absenderadresse wird dann auch der SPF Record (Sender Policy Framework) geprüft.

Dann gibt es noch den Brief oder eben den Header. Das ist der Absender und Empfänger im Briefkopf oder eben das, was der Mailclient (beispielsweise Outlook) darstellt.

Konkret sind die folgenden Attribute für den Umschlag (also für den Mailserver)

mail from:
rcpt to:
Die folgenden Attribute werden vom Mailclient benutzt (beispielsweise Outlook)
From:
To:
Reply-To:

Bildquelle: https://www.proofpoint.com/de/corporate-blog/post/how-does-email-spoofing-work-and-why-it-so-easy

Tests mit Exchange Online

Ich habe das ganze mal mit Exchange Online geprüft und die verschiedenen Arten von Weiterleitungen ausprobiert.

SMTP Forwarding

Als erstes habe ich das SMTP Forwarding gesetzt

Set-Mailbox m.muster@icewolf.ch -ForwardingSMTPAddress "smtp:andres.bohren@isolutions.ch"
Get-Mailbox m.muster@icewolf.ch | fl *Forward*

Authentication-Results: spf=pass (sender IP is 40.107.13.129)
 smtp.mailfrom=icewolf.ch; isolutions.ch; dkim=pass (signature was verified)
 header.d=icewolfch.onmicrosoft.com;isolutions.ch; dmarc=fail action=none
 header.from=isolutions.ch;compauth=pass reason=130
From: Andres Bohren <Andres.Bohren@isolutions.ch>
To: "m.muster@icewolf.ch" <m.muster@icewolf.ch>
Subject: Forward SMTP
Return-Path: Max.Muster@icewolf.ch

Forwarding mit MailContact

Get-Contact -Identity aboIsol | fl Identity, RecipientTypeDetails, WindowsEmailAddress
Set-Mailbox m.muster@icewolf.ch -ForwardingAddress aboIsol -ForwardingSMTPAddress $Null

Authentication-Results: spf=pass (sender IP is 40.107.8.100)
 smtp.mailfrom=icewolf.ch; isolutions.ch; dkim=pass (signature was verified)
 header.d=icewolfch.onmicrosoft.com;isolutions.ch; dmarc=fail action=none
 header.from=isolutions.ch;compauth=pass reason=130
From: Andres Bohren <Andres.Bohren@isolutions.ch>
To: "m.muster@icewolf.ch" <m.muster@icewolf.ch>
Subject: Forward to Mailcontact
Return-Path: Max.Muster@icewolf.ch

Weiterleitung über Exchange Transport Rule

Zuerst müssen natürlich mal die bestehenden Forwardings gelöscht werden.

Set-Mailbox m.muster@icewolf.ch -ForwardingAddress $null -ForwardingSMTPAddress $null
Get-Mailbox m.muster@icewolf.ch | fl *Forward*

Dann habe ich eine Exchange Transport Regel erfasst

Hier wird der SRS Header im Return-Path gesetzt. Allerdings sind maximal 600 Transport Rules möglich.

Authentication-Results: spf=pass (sender IP is 40.107.4.120)
 smtp.mailfrom=icewolfch.onmicrosoft.com; isolutions.ch; dkim=pass (signature
 was verified) header.d=icewolfch.onmicrosoft.com;isolutions.ch; dmarc=fail
 action=none header.from=isolutions.ch;compauth=pass reason=130
From: Andres Bohren <Andres.Bohren@isolutions.ch>
To: "m.muster@icewolf.ch" <m.muster@icewolf.ch>
Subject: Forward Transport Rule
Return-Path: bounces+SRS=DvlLD=JD@icewolfch.onmicrosoft.com

Weiterleitung über eine Verteilerliste mit externen Teilnehmern

Ich habe eine Verteilerliste erstellt mit dem externen Mail User als Mitglied

Damit ich von Extern an die Verteilerliste senden kann, muss man dies noch hier einstellen

Auch hier wird der SRS Header im Return-Path gesetzt.

Authentication-Results: spf=pass (sender IP is 40.107.13.97)
 smtp.mailfrom=icewolfch.onmicrosoft.com; isolutions.ch; dkim=pass (signature
 was verified) header.d=icewolfch.onmicrosoft.com;isolutions.ch; dmarc=fail
 action=none header.from=isolutions.ch;compauth=pass reason=130
From: Andres Bohren <Andres.Bohren@isolutions.ch>
To: "GroupWithExternalMembers@icewolf.ch"
 <GroupWithExternalMembers@icewolf.ch>
Subject: Test Forwarding Group 3
Return-Path: bounces+SRS=DvlLD=JD@icewolfch.onmicrosoft.com

Outlook Regeln

Das Forwarding mit den Outlook Regeln hat nicht geklappt, wie man auf den folgenden Screenshots sehen kann

Fazit

Wie ich in meinen Tests festgestellt habe, wird der SRS Header nur bei den Transport Rules und den Verteilerlisten gesetzt. Bei der SMTP und MailContact/MailUser Weiterleitung wird der Header schon anderweitig umgeschrieben, so dass SRS nicht mehr notwendig ist.

Man kann dazu absolut nichts konfigurieren. Funktioniert einfach so out of the Box. Aber dann doch nicht ganz so, wie in den beiden ersten Links beschrieben.

Liebe Grüsse
Andres Bohren

posted @ Tuesday, April 6, 2021 3:29 PM | Filed Under [ Exchange O365 ]

New M365 network connectivity testing tool

Hallo zusammen,

Neu gibt es das https://connectivity.office.com Tool um die Netzwerkverbindung mit Microsoft 365 zu testen.

Auf der "Network Health Status" Seite werden von Microsoft bekannt ausfälle dargestellt.

Der Standort kann automatisch ermittelt oder manuell angegeben werden.

Beim Test wird eine Exe Heruntergeladen, welches man ausführen muss, um noch genauere Resultate zu erhalten

Das Programm macht dann über 600 verschiedene Tests

Danach sieht man, wo die Front Door Services für die einzelnen Dienste ist (jedenfalls für Exchange und SharePoint)

In den Details sieht man wie der DNS Aufgelöst wurde und wieviel die Netzwerk Latenz dorthin beträgt.

Grüsse
Andres Bohren

posted @ Tuesday, April 6, 2021 9:53 AM | Filed Under [ O365 ]

Use Azure Automation for Exchange Online PowerShell Script - Part 2

Hallo zusammen,

Nach dem ersten Teil des Artikels, folgt nun der zweite.

Ich wollte noch ein paar Komponenten dazufügen:

  • Import CSV von einem Azure Storage
  • Ein Logfile erstellen und in Azure Storage abspeichern

Als einfaches Beispiel habe ich das cmdlet Set-CASMailbox genommen, bei dem ein paar Mailboxen über ein CSV exkludiert werden sollten

Zuerst einmal müssen die Variablen für Storage Account und Storage Key erfasst werden. Den Storage Key kann man Encrypted abspeichern.

Diese Variablen lassen sich einfach im Script wieder auslesen

$StorageAccountName = Get-AutomationVariable -Name "StorageAccountName"
"StorageAccountName --> $StorageAccountName"

$StorageAccountKey = Get-AutomationVariable -Name "StorageAccountKey"
"StorageAccounKey --> $StorageAccountKey"

Danach habe ich das ganze Script geschrieben:

"Getting Variables"
$StorageAccountName = Get-AutomationVariable -Name "StorageAccountName"
#"StorageAccountName --> $StorageAccountName"

$StorageAccountKey = Get-AutomationVariable -Name "StorageAccountKey"
#"StorageAccounKey --> $StorageAccountKey"

#Connecting to Exchange Online...
"Connecting to Exchange Online..."
$connection = Get-AutomationConnection –Name AzureRunAsConnection
$tenant = "icewolfch.onmicrosoft.com"
Connect-ExchangeOnline –CertificateThumbprint $connection.CertificateThumbprint –AppId $connection.ApplicationID –ShowBanner:$false –Organization $tenant

#Create Logfile
$logfile = (get-date).ToString("yyyyMMdd_hhmm") + ".log"
$LogPath = $env:temp + "\$logfile"
Add-Content -Path $LogPath "Starting Script"

#Download CSV from Azure Storage
"Download CSV from AzureStorage"
$DestinationFile = $env:temp + "\CASMailboxExclude.csv"
$StorageContext = New-AzureStorageContext -StorageAccountName $StorageAccountName -StorageAccountKey $StorageAccountKey
Get-AzureStorageFileContent -ShareName "csv" -Path "/CASMailboxExclude.csv" -Context $StorageContext -Destination $DestinationFile

#Import CSV
$CSV = Import-CSV -Path $DestinationFile
$ExcludeArray = $CSV.Email
#"ExcludeArray..."
#$ExcludeArray

#Loop through Mailboxes
$CASMBX = Get-CASMailbox
Foreach ($MBX in $CASMBX)
{
 $Email = $MBX.PrimarySmtpAddress
 #Write-Host "Email: $Email"
    "Email: $Email"
 If ($ExcludeArray -match $Email)
 { 
  #Write-Host "$Email is in the ExcludeArray" -foregroundColor yellow
  "$Email is in the ExcludeArray"

 } else {
  Set-CASMailbox -Identity $Email -PopEnabled $false -ImapEnabled $false -SmtpClientAuthenticationDisabled $true
 }
}

Add-Content -Path $LogPath "Done"

#Upload Logfile
"Upload Logfile to AzureStorage"
Set-AzureStorageFileContent -ShareName "csv" -Path "/$logfile" -Context $StorageContext -Source $LogPath

Wie man sieht, hat das Script POP3, IMAP und SMTPAUTH überall dort deaktiviert, wo es möglich ist.

Und auch die Logfiles wurden auf dem Azure Storage abgelegt.

Grüsse
Andres Bohren

posted @ Monday, April 5, 2021 2:47 PM | Filed Under [ Exchange Azure ]

Powered by:
Powered By Subtext Powered By ASP.NET