Early August 2022, the Vietnamese organization GTSC Cyber Security noticed anomalies in their SOC and they discovered their Exchange servers were under attack. They quickly determined the attack utilized an unpublished Exchange security vulnerability. Due to earlier Exchange attacks GTSC quickly uncovered the vulnerability and Microsoft was informed about the vulnerability at this time. Microsoft needed some time as well for investigation and remediation, but the Exchange world was made aware of potential 0-day vulnerabilities this Thursday (09/29) through the following tweet by security researcher Kevin Beaumont:
ENow Software's Exchange blog built by Microsoft MVPs for IT/Sys Admins.
Michel de Rooij
I'm a Microsoft 365 Apps and Services MVP, with focus on Exchange, Identity, and an affection for PowerShell. I'm is a consultant, publisher of EighTwOne, published author, and speaker.
Yesterday, the Exchange Product made several announcements related to Exchange Server. The overall message throughout these announcements can be interpreted as that Microsoft is publicly declaring to be committed to developing and supporting the Exchange Server product. This is especially of interest to those customers running it as part of their on-premises infrastructure and assuring those that believe the road ahead was a dead end, eventually forcing them to move to Exchange Online, or look for alternatives.
In the announcement that was part of the release of the most recent set of Cumulative Updates for Exchange Server 2019 and 2016, Microsoft introduced some changes – features if you will – which were received with enthusiasm. An overview of these changes was given in a recent ENow blog article: "Exchange Cumulative Updates - April 2022". However, I want take the discussion further and zoom in on one of those features, which also happens to be a popular topic for customers running Exchange Hybrid deployments: The Last Exchange Server.
Back in September 2019, Microsoft announced it would start to turn off Basic Authentication for non-SMTP protocols in Exchange Online on tenants where the authentication protocol was detected as inactive. This is part of an overall movement to deprecate the less secure Basic Authentication, which is unfit to face the security challenges of the modern world, being subject to things like password spray attacks. It's modern successor, modern authentication or OAuth2, uses a token and claim based mechanism contrary to sending accounts and passwords, and is the preferred authentication method. When combined with Azure AD for authentication, Modern Authentication also supports features such as Multi-Factor Authentication or Conditional Access.
Anyone who has participated in migrations or transitions to Exchange is probably familiar or had to work around potential issues caused by the nickname cache. A “cache,” also known by its file extension, NK2 in older Outlook clients, is a convenience feature in Outlook and Outlook on the web (OWA). It lets users pick recipients from a list of frequently-used recipients. This list is displayed when the end user types in the first few letters:
Anyone who has participated in migrations or transitions to Exchange has most likely encountered or has had to work around potential issues caused by the nickname cache. A “cache,” also known by its file extension, NK2 in older Outlook clients, is a convenience feature in Outlook and Outlook WebApp (OWA) which lets users pick recipients from a list of frequently-used recipients. This list is displayed when the end user types in the first few letters.
The potential issue revolves around end users using those lists to send messages, as the list contains cached recipient information. Because this information is static, it may become invalid at some point. Thus, when users pick recipients when sending messages, they may be sending messages to non-existent recipients or invalid e-mail addresses, which create issues like non-delivery of e-mail.
In an earlier version of Outlook, this information was stored in local .NK2 files. In Outlook 2010 and up, this information is stored in your mailbox (AutoComplete Stream). Unfortunately, OWA utilizes its own cache mechanism while Outlook stores recipient information in other locations as well, like the ‘Suggested Contacts’ folder for example.
After some recent Exchange troubleshooting I decided to do a small write-up on an attribute most people working with Exchange know about, the infamous exchangeLegacyDN.
In the early days of Exchange, the NT world was flat. Exchange utilized its own hierarchical X.400 directory service and to uniquely identify objects it used an attribute called obj-Dist-Name. It contained a constructed value using elements like organization, containers and the canonical name to construct the entry, e.g. /o=Contoso/ou=EMEA/cn=Recipients/cn=User.
For those involved with Exchange migration projects or managing Exchange environments, at some point you probably have experienced a situation where individuals ended up with duplicate items in their mailbox. Duplicate items can be caused by many things, but most common are:
Many customers nowadays are running a virtualized Exchange environment, utilizing Database Availability Groups, load balanced Client Access Servers and the works. However, I also see environments where it is up to the Hypervisor of choice on the hosting of virtual machines after a (planned) fail-over. This goes for Exchange servers, but also for redundant infrastructure components like Domain Controllers or Lync Front-End servers for example.