An interesting and worthwhile interview (available on YouTube) with security researcher Amit Serper reveals a lot more detail about the Autodiscover credential leak reported by Guardicore last month. The interview (with three Office 365 MVPs) goes through the collection of leaked credentials, how Serper tried to reproduce the problem, and his interaction with Microsoft. It’s a real pity Serper didn’t include the information in his original report as it would have taken a lot of heat out of the situation.
Lots of excitement was generated when Guardicore revealed a purported vulnerability with the Exchange Autodiscover service. However, the almost total lack of detail about the configuration used for testing and to generate the reported results makes it impossible for Exchange administrators to check the theory against their own deployment. I don’t think a problem exists with Exchange Online, but it’s possible that poor DNS practice or flawed third-party clients could cause an issue with on-premises servers. The case remains to be proved.
From November 1, 2021, Microsoft requires Outlook 2013 Service Pack 1 (with fixes) as the minimum client version to connect to Exchange Online. Given all the publicity about attacks against the on-premises version of Exchange earlier this year, it’s a wonder why organizations continue to allow people to use outdated client software to connect to Exchange Online. In any case, the drop-dead date is November 1. If you have any old Outlook 2007, Outlook 2010, or Outlook 2013 (before SP1) clients, it’s time to start upgrading.
The Outlook Places service uses metadata stored for conference rooms and room lists to help users find suitable meeting places. The metadata surfaces in Outlook’s Room Finder component (shared between OWA and Outlook desktop). Obviously, the better populated the room metadata is, the more useful it will be, once we all start meeting in conference rooms again!
When contacts are added to an organizations Global Address List (GAL), they do not always populate in the users personal device contacts depending on what app, device, etc. is being used. This becomes problematic when users working from outside the office are unable to contact the IT Service Desk, HR, or other internal services. To solve the problem, this article introduces a PowerShell script that will read a set of standard contacts from a CSV file and write them as personal contacts to user mailboxes. Mobile devices can then synchronize these contacts along with others created by the user.