Glen's Exchange and Office 365 Dev Blog

In this post I'm going to look at what you need to do in your EWS Managed API code to support using Hybrid Modern Authentication where previously you've been using Basic or Integrated Authentication (both of which are susceptible to password spray attacks). If you don't know what  Hybrid Modern Authentication   is put simply it brings to Exchange OnPrem email clients the security benefits of Modern Authentication offered by Azure AD to Office365 tenants. If your already using OAuth to connect to Office365 you have most of the work already done but you will still need logic to ensure you have the correct Audience set in your token when that code is used against an OnPrem Mailbox.  Prerequisites  You need to be using Hybrid Exchange or more specifically  Hybrid Office 365 tenant is configured in full hybrid configuration using Exchange Classic Hybrid Topology mode ref  https://docs.microsoft.com/en-us/exchange/clients/outlook-for-ios-and-android/use-hybr...

Last July Microsoft announced here they would be disabling basic authentication in EWS on October 13 2020 which is now a little over a year away. Given the amount of time that has passed since the announcement any line of business applications or third party applications that you use that had been using Basic authentication should have been modified or upgraded to support using oAuth. If this isn't the case the time to take action is now. When you need to migrate a .NET app or script you have using EWS and basic Authentication you have two Authentication libraries you can choose from ADAL - Azure AD Authentication Library (uses the v1 Azure AD Endpoint) MSAL - Microsoft Authentication Library (uses the v2 Microsoft Identity Platform Endpoint) the most common library you will come across in use is the ADAL libraries because its been around the longest, has good support across a number of languages and allows complex authentications scenarios with support for SAML etc. The ...

There has been a lot of information of late from security researchers and Microsoft themselves about Inbox rules being used to compromise workstations and for use in more pervasive security breaches. One of the more interesting one is is  https://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/ Which has a pretty nice EWS script  https://github.com/OfficeDev/O365-InvestigationTooling/blob/master/Get-AllTenantRulesAndForms.ps1 for enumerating Rules, specifically they are looking for a Client side rule exploit so this script is enumerating all the Extended Rule Objects in the FAI collection of the Inbox. In Exchange you can have Server side rules which run regardless of the connection state of any client or Client only rules which only run when the client is connected for more information see https://support.office.com/en-us/article/server-side-vs-client-only-rules-e1847992-8aa1-4158-8e24-ad043decf1eb .  So what the above...

I've had some time recently to do some much needed updates to my Exch-Rest module so it now supports both Azure Cloud Shell and PowerShell Core on Linux (tested on RHEL,CentOS, Debian and Ubuntu). So now you can logon to an Office365 Mailbox using this Module with Powershell on Linux and send Email or a Skype for Business Message or do some mailbox reporting eg The requirements on Linux is you need to be using the latest version of PowerShell core installed as per  https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell-core-on-linux?view=powershell-6 .This ensures that all the required .net Core libraries will be available as older version of .Net core didn't have some of the libraries I'm using and I didn't want to backport for older versions.  Also because there are no Linux forms to interact with for authentication you need to pass in the credentials to use via a PSCredential and the code will use the password grant to get the Token e...