Deprecation of the classic Exchange Admin Center
The new Exchange Admin Center has been available for quite some time and was designated reaching general availability back in April. With feature parity met, and in many cases exceeded, it is no doubt that the Exchange team is now planning the deprecation of the classic Exchange Admin Center.
Starting this month features will be redirected away from the classic admin center with the planned removal of the classic EAC by September 2022. Check out Microsoft’s timeline in the image below.
To use the new Exchange Admin Center point your browser to https://admin.exchange.microsoft.com or from the classic Exchange Admin Center select the toggle to Try the new Exchange Admin Center in the top-right of the screen.
New end date for Basic Authentication
Since 2018 Microsoft has announced the blocking of basic authentication. However, due to the pandemic, that date has shifted a few times. Back in February, it was announced that the deprecation of basic auth had been put on hold until further notice. In September Microsoft announced new deadlines for the deprecation of basic authentication for all Exchange protocols. This date is October 1st, 2022. After this date, any application connecting to Exchange Online will be required to leverage modern authentication (OAuth 2.0). The only exception to this is SMTP Auth which can continue to use basic authentication.
Note: Prior to October 1st, 2022, Microsoft will continue to disable basic auth on protocols in tenants where basic auth is not detected.
For devices and applications that integrate with Exchange Web Services, such as voicemail, ticketing systems, or line of business applications, these will be required to support modern authentication. One option is to leverage certificate-based authentication leveraging an Azure app. However, it is better to switch the EWS integration over to Microsoft Graph as Microsoft plans to deprecate EWS integration starting September 30th, 2022. Microsoft is positioning Microsoft Graph to be the sole entry point for all app integrations rather than having separate entry points for each Office 365 workload. This reduces the attack footprint of the Office 365 service. I would also recommend looking into Application Access Policies. These policies limit what mailboxes an app can access. Be sure to check your vendor’s documentation for guidance on connecting these apps to Office 365 with modern authentication.
For PowerShell, I recommend using the Microsoft Exchange Online PowerShell Module. This module supports both modern auth and is a requirement if your admin account has multi-factor authentication enabled (which I hope it does!). I recommend checking out this article for more information on how to use this module. Also, you may want to look into the Azure Cloud Shell. Check out the tutorial; Using Exchange Cmdlets in Azure Cloud Shell.
For POP and IMAP, Microsoft added OAuth support. However, this still requires your POP or IMAP application to support OAuth. For integrated apps that use POP or IMAP, like helpdesk ticketing systems, I would recommend looking for other methods of integration rather than using POP or IMAP. Using our helpdesk ticketing system example, look to see if the app can integrate with EWS or the Graph instead. For clients, see if you can switch those users over to a new client that supports a direct Exchange connection. My recommendation is to get rid of POP and IMAP entirely and globally shut down those legacy protocols.
The most significant impact of this announcement will be on ActiveSync. Countless native mail apps use ActiveSync to access their Office 365 mail. I highly recommend migrating your user base to Outlook mobile (for iOS and Android). Outlook Mobile supports both modern authentication and multi-factor authentication. It is worth noting that some native mail apps, such as those included in iOS 11+, have modern authentication support. However, pushing users to Outlook Mobile versus upgrading their phones is the path of least resistance. Not to mention your helpdesk or IT department will only need to support one mail client and have greater control protecting corporate data via mobile application management policies from Intune.
To track which devices and applications are signing in with legacy authentication, you can use the Azure AD Sign-ins dashboard. Microsoft covers this process in this article.
Once you have eliminated legitimate basic auth clients, you can then move to block basic auth in your tenant prior to the Microsoft deadline. Microsoft allows administrators to disable basic auth by the client type. These settings are found in the main Microsoft 365 Admin Center by navigating to Settings > Org Settings > Modern Authentication.
If you need granularity, especially if you need to make exceptions for basic auth, I recommend implementing conditional access policies instead.
You will receive message center notifications when Microsoft is planning to disable basic auth in your tenant and when basic auth has been fully disabled. Once you have received the latter notification you should review any conditional access or authentication policies that dealt with basic authentication.
For the latest on Microsoft’s plan to disable basic authentication review: Basic Authentication and Exchange Online – September 2021 Update
New endpoint for SMTP AUTH clients needing TLS 1.0 / 1.1
Exchange Online ended support for SMTP AUTH clients using TLS 1.0 and TLS 1.1 in October of 2020. In 2022 Microsoft plans to block SMTP AUTH clients using TLS 1.0 and TLS 1.1 from connecting to smtp.office365.com. Only TLS 1.2 will be accepted at smtp.office365.com.
With this deadline set, Microsoft has deployed a new SMTP AUTH endpoint, smtp-legacy.office365.com, to support TLS 1.0 and TLS 1.1 clients. This endpoint is disabled by default and requires administrators to opt-in (effectively agreeing to lower their security posture). To enable this endpoint an administrator would run the following command.
C:\> Set-TransportConfig -AllowLegacyTLSClients $true
A best practice is to not enable this and only leverage devices that support TLS 1.2.
In addition, it’s best to disable SMTP AUTH globally (using Set-TransportConfig) and only enabling SMTP AUTH on the mailboxes that absolutely require it (using Set-CASMailbox). For more information on that process check this article: Enable or disable SMTP AUTH in Exchange Online
New minimum Outlook version for M365
Starting November 1st, 2021, only Outlook 2013 SP1 (build 15.0.4971.1 and greater) will be able to connect to Microsoft 365 services. This means older Outlook 2013 builds, and Outlook 2010 and earlier will not be able to connect to Microsoft 365.
This new requirement goes hand in hand with the deprecation of basic auth (modern auth is only available in Outlook 2013 SP1+) and an initiative to roll out HTTP/2 to all of Microsoft 365. HTTP/2 is a more efficient web protocol that requires newer Office clients.
That said, I recommend you do not use Outlook 2013 either. Despite, all the patching and registry keys required to make it work, Outlook 2013 does not support many key features such as auto-expanding archives, all of the shared calendaring improvements, or, cloud attachments. For the best experience with Microsoft 365, it is always best to run the latest version of Office.
Changes to Sender Rewriting Scheme
Sender Rewriting Scheme is used to help identify legitimate forwarded mail. Take, for example, a scenario where a user at contoso.com sends an email to a user at supertekboy.com. That user at supertekboy.com has a mailbox rule which automatically forwards that message to exchangeservergeek.com. When exchangeservergeek.com performs its SPF check it will fail because supertekboy.com is not permitted to send mail on behalf of contoso.com (the original sender). SRS combats this by changing the P1 header to that of the forwarder, in this case, supertekboy.com. This way the SPF check is performed against supertekboy.com, which will pass, and not contoso.com.
Note: SRS does not change the P2 header. The P2 header is the email address displayed in Outlook. This means the recipient of the email sees the original sender, not the forwarder.
Microsoft has announced changes coming to the way it implements Sender Rewriting Scheme (SRS) in Exchange Online.
The first is that SRS was not used in all forwarding scenarios. For example, mailbox forwarding, where an administrator configures the mailbox to forward to a mail contact, was not subject to SRS. Starting in November, all methods of automatic forwarding in Exchange Online will be switched to SRS. This, however, does not include mail automatically forwarded through an on-premises environment.
For this comes the second change. Administrators can now optionally apply SRS on their “Office 365 > Your Organization’s Email Server” connector. Previously, SRS was not considered for this scenario because mail from Exchange Online to Exchange on-premises was always trusted and did not require an SPF check. An administrator can now enable SRS on their “Office 365 > Your Organization’s Email Server” connector via the New-OutboundConnector and Set-OutboundConnector cmdlets.
The last scenario is for messages sent to Exchange Online that failed the original SPF check. When Exchange Online automatically forwards these messages they will be sent out via a special relay pool, will not be rewritten with SRS, and the original SPF failure will be preserved in the message header.
Need a refresher from Ignite 2020?
With Ignite 2021 only a couple of weeks away (November 2–4, 2021), it might be time to brush up on some of the topics covered at Ignite 2020. If you need a refresher on all the Exchange features announced at Ignite, I highly recommend checking out the article 15 Ignite sessions every Exchange admin should see (2020 edition). In this article, there are extensive notes on what each session contained. Also, those notes include timers if you need to jump to a specific topic.
Further Reading
Here are some articles I thought you might like.
- On the Line with Cohesity #44: Updates on M365 and more!
- Easily Connect to Exchange Online with PowerShell
- 15 Ignite sessions every Exchange admin should see (2020 Edition)
So what do you think is coming next? What would you like to see? Drop a comment below or join the conversation on Twitter @SuperTekBoy.
Leave a Reply