Exchange Server

Microsoft Exchange Server

Exchange Server

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default


For many organizations, Exchange Online (EXO) will be their first access point into Microsoft 365. While there are many similarities in how the cloud service is managed compared to an on-premises Exchange deployment, there are also many new concepts and risks introduced. The responsibilities of a traditional Exchange Administrator after moving to EXO are vastly different from what they were previously used to.

In this article, I will outline the most important steps an Exchange Online Administrator needs to take to make EXO secure by default. While there are a lot of nifty security tools we can leverage with the appropriate licensing, all the steps outlined in this article can be achieved with basic licenses.

Disable Legacy Authentication

This one should be no surprise to anyone. The first step that should be taken to make your Exchange Online environment secure by default is to disable Legacy Authentication. In the context of Microsoft 365, Legacy Authentication is not a single protocol, more an umbrella term used to describe any protocol that uses Basic Authentication. Steve Goodman wrote a great article on how to do this which I strongly recommend you review.

For tenants with Azure Active Directory Premium, Conditional Access can be used to block Legacy Authentication at a tenant, app, or user level. But as Conditional Access only applies after the initial authentication occurs, Legacy Authentication should still be turned off at a service level in Exchange.

Microsoft is pushing to disable Legacy Authentication and has recently announced that they will be retiring it from any tenant that is not currently using it. Owners of these tenants will be notified by a Message Center Notification.

Implement Multi-Factor Authentication

Multi-Factor Authentication (MFA) is an extremely effective method to provide additional verification for user sign-ins. With the abundance of Phishing attempts that occur daily for large organizations, it can often be the last line of defense against an attacker gaining access to confidential data. It is also extremely easy to implement.

For tenants with Azure Active Directory Premium, Conditional Access can be implemented to allow for some cool scenarios such as bypassing MFA on trusted devices, from trusted networks and even reassess the requirement based on user state changes with the continuous evaluation feature.

If you don’t have Azure AD Premium though, you can still protect your tenancy with Azure AD Security Defaults. This will allow you to enforce MFA for all users very easily, although the flexibility of Conditional Access is lost here.

Understand and Secure Exchange Online Mail Connectors

Out of the box, Exchange Online has default send and receive connectors and unlike Exchange On-Prem, you can’t see or modify them. Exchange Online has some top-class mail protection available through Microsoft Defender for Office 365 but that requires additional licensing to leverage. Some organizations will opt to maintain a third-party service instead of fully moving inbound and outbound mail protection to Microsoft, and that’s fully supported in Exchange Online however there are some considerations to this configuration.

The most important consideration is the default connectors I mentioned above. When you set your MX records to route inbound mail via a third-party gateway, it’s important to remember that MX records are not an enforced mail route, they are simply letting other mail systems know the advertised/preferred public mail route. By default, nothing is stopping external systems from sending mail directly to Exchange Online, bypassing your third-party protections.

To protect against this, a new connector is required in Exchange Online to ensure that mail from external domains is only accepted from your designated sources. This connector needs to specify “*” as the domain to catch all inbound mail and can be set up like the example shown in Figure 1:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 1: Connector enforcing secure inbound mail route.

My recommendation is that for any mail connectors you set up, to use certificate validation wherever possible and to enforce TLS. IP-based restrictions are available but not as secure as using a public certificate and enforcing TLS.

With this connector set up, when a mail is sent directly to Exchange Online for your organization, it will be denied with a delivery status notification 5.7.1:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 2: Mail is rejected with DSN 5.7.1 if it has not routed through your specified endpoint.

Implement SPF, DKIM, and DMARC

Sender Policy Framework (SPF), DomainKeys Identified Mail Standard (DKIM), and Domain-Based Message Authentication, Reporting & Conformance (DMARC) are email security controls that protect public mail domain reputation. They are used to ensure that your outbound mails can be verified while helping to ensure spoofed mails from your domains are blocked by recipients.

While you can’t control the protection standards of other organizations’ mail systems, you can help them to determine if mails received from your domains are legitimate and be informed when your domain is being spoofed.

Let’s look at a brief description of each control:

  • SPF uses a public DNS TXT record to inform organizations about the authorized source mail systems for your domain. It does this by publishing source IP addresses/ranges for your domain. It also has a lookup functionality to allow you to specify A records or MX records as authorized sources.
  • DKIM does a similar job to SPF by allowing you to verify the source of your emails but can be more effective in complex scenarios as it uses certificate signing for outbound mails. An encrypted header is added to outbound mail using a DKIM signing certificate, which can be validated against a public key that is advertised via a public DNS CNAME record.

For a detailed breakdown of SPF and DKIM setup, check out Alan Byrne’s article here.

  • DMARC is a little different in that it’s not a specific control, rather a set of instructions that external mail servers should honor when validating SPF and DKIM from your domain. DMARC works by publishing these “instructions” in public DNS for receiving servers to follow when they get an email from your domains. This record is a TXT record that can specify the following values:
    • v – What version of DMARC is being used? (Currently, the only version is version 1)
    • aspf – Should SPF be verified?
    • adkim – Should DKIM be verified?
    • p / fo – What should happen if SPF and/or DKIM fail? (Nothing, Quarantine, Reject)
    • rua – Should aggregate reports be sent back you your mail system and to what address?
    • ruf – Should individual failure / forensic reports be sent back to your mail system and to what address?
    • sp – Should there be a separate policy for subdomains?
    • pct – *What percentage of mails should DMARC apply to?

*When rolling out DMARC, you can specify a percentage of mail to apply it to, gradually working towards 100%

A fully implemented DMARC TXT record will look like this:

With each of these controls in place, you aren’t just helping to protect your domain against spoofing, but also minimizing the likelihood that your legitimate mails will be seen as spam on the recipient side. This doesn’t replace having appropriate outbound mail filtering in place but goes a long way to protecting your public domain and gaining insights into potential issues.

Enable Admin Consent for Azure AD Apps

Securing user authentication is an effective step in preventing unauthorized access to data within your organization but there are other means that attackers can use to get control of a user’s account. One of these methods is by creating an application which requests users to grant permissions to aspects (scopes) of their data / profile. This can be very useful for application developers who need to access services on behalf of the user, say for example, allowing a scheduling app access to a user’s mailbox / calendar.

The risk with this type of access is that we don’t (by default) predefine which applications can access our tenancy and a user may end up consenting to access from a malicious app. Once the application is granted permissions on the defined scopes, it doesn’t need the users password or MFA to access data on behalf of the user. The user will be prompted to consent when they sign up for the app, similar to Figure 3:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 3: Request for consent from Graph Explorer.

To combat this risk, you can configure Admin Consent in Azure AD. This prevents users from directly granting consent to applications and instead will allow an administrator to approve it after ensuring it’s safe. I recommend checking out this article for a detailed breakdown of how to implement admin consent in Azure AD.

Implement External Email Tagging

Helping users to easily identify external mail can go a long way towards protecting against phishing/spoofing attempts. Adding a tag to mail as it comes in makes it clear to end-users that they should be extra vigilant if the mail contains sensitive content. There are a few ways to implement tagging for external mail, each delivering a similar result, so whichever one you use is up to you.

The first way to accomplish this is to implement a transport rule to prepend a disclaimer to emails that originate externally such as the one shown in Figure 5:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 4: Prepend a disclaimer to external mails.

This rule can even add HTML content to draw the user’s attention, an example of this is shown in Figure 5:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 5: HTML Disclaimer.

The drawback to this method is it tends to break any message preview function in mail clients as the first few lines of text will always be the disclaimer.

Another way this can be implemented is simply prepending some text to the subject. This can also be done with a transport rule. To stop this rule triggering every time there is a reply to a message trail, make sure to add an exception to the rule as shown in Figure 6:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 6: Prepend a tag to the message subject.

For organizations who solely use Outlook to access Exchange Online from different platforms, there is also the built in external email tag functionality which can be enabled organization wide. This tag (Shown in Figure 7) will only show up in Outlook / Outlook Web so the mail apps in your organization will need to be considered.

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 7: External tag in Outlook.

Turning on this feature is as simple as running a single command in Exchange Online PowerShell as shown in Figure 8:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 8: Enabling external email tagging in Outlook.

Mobile Application Management

Microsoft Endpoint Manager (MEM) / Intune – if you are licensed for it – can provide some powerful features to ensure that when users connect to data in your organization, that the data can be protected from export to an untrusted device or location. By implementing Mobile Application Management Policies, export of data from corporate applications (such as Outlook Mobile) can be restricted. This unlocks a lot of BYOD scenarios without putting corporate data at risk. It’s important to note that Mobile Application Management will only work with supported applications so if enabling MAM, make sure to also restrict mobile access to these applications using Conditional Access as shown in Figure 9:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 9: Enforcing supported MAM apps on mobile via Conditional Access.

Configure Microsoft Defender for Office 365

Microsoft Defender for Office 365 (formerly Office 365 ATP) is a powerful tool for protecting Exchange Online from all types of malicious email traffic such as Phishing, Malware and regular Spam. While it does require some premium licensing, the feature-set and protection available provides a lot of value for money by making available a lengthy list of features.

Getting started with Defender for Office 365 doesn’t need to be a pain either.

Define Data Loss Prevention Policies

Data Loss Prevention (DLP) policies can allow organizations to secure and control data as it leaves the organization. By defining DLP policies particular patterns (or Sensitive Information Types) can be detected within content as it is shared externally, and a set of rules are applied to determine if the data is allowed to exit the tenancy.

For example, an email with a list of credit card numbers can be blocked due to the contents, while a single credit card number can be sent but with Office Message Encryption applied. It’s important to note that DLP should be used alongside user vigilance and training, it isn’t designed to replace good practice when it comes to protecting data.

Once defined, DLP can then be extended to SharePoint Online, OneDrive and even Microsoft Teams. To make sure you can extend the policies, they need to be configured as Unified Policies within the Microsoft 365 Compliance Center. Having a single set of rules in the tenant for what can (or can’t) be shared externally via any method, will avoid “Loopholes” in the controls.

For an in-depth look at DLP Policies in Office 365 I highly recommend checking out this article by Paul Cunningham.

Note: DLP for Exchange requires a minimum of Exchange Online Plan 2 licensing


There are a lot of methods you can implement to improve the security of your Exchange Online environment, and even more tools out there made by Microsoft and third-party companies that can assist with security initiatives.

And while there are many advanced features and settings to consider down the road, in this article I’ve detailed some of the most important steps that can immediately be implemented out-of-the-box to align your Exchange Online tenant with a good security baseline and posture.

Source Practical 365

read more
Exchange ServerOffice 365

Microsoft 365 E3 License vs. Microsoft 365 E5 License


There is little debate over whether the Microsoft 365 E5 license is a fantastic product. However, over the past two years, the E5 license offering has matured greatly, and it seems like Microsoft customers would be even more receptive to the upgraded license. If anything, customers will see major benefits from a one-stop-shop approach that replaces the need for third-party endpoint protection and mail hygiene solutions with Microsoft 365 E5 services like Microsoft 365 Defender for Endpoint and Microsoft 365 Defender for Office 365.

But does everything residing only in Microsoft 365 E5 truly belong there?  I’ve been pondering this question for a while now and believe that there is a compelling case for certain premium features to make the journey over to Microsoft 365 E3.

Pros vs. Cons

The benefits are two-fold in my opinion: First, it makes important security features that are no longer simply “nice to have” more accessible to a wider customer base.  It also gives Microsoft the incentive to stay at the leading edge of innovation and bring new and exciting features to their premium offering. While this rationale definitely made sense to me, I was curious as to what my colleagues thought, so I decided to pose the question on my Twitter feed:

Figure 1: Opening a can of worms on social media around the Microsoft 365 E5 debate.

The responses were numerous and quite varied, with many opinions on the matter. Before we examine the responses, it should be noted this licensing discussion revolves around Microsoft 365, not Office 365 – two very different things. For example, basic Microsoft 365 E3 security capabilities are not included within the Office 365 E5 license. For more information on how Microsoft 365 and Office 365 differ, you can also refer to this Microsoft page.

Which Features are the Most Wanted in Microsoft 365 E3?

After tallying up the responses, most of those voting for Microsoft 365 E5 were only voting for those specific E5 features.  However, there were two clear favorites in Privileged Identity Management and Auto labelling (Table 1):

Microsoft 365 E3 License vs. Microsoft 365 E5 License
Table 1: Twitter survey responses.

Other non-feature specific responses included:

  • Eliminate add-on licenses such as Viva and SharePoint Syntex, and add these to Microsoft 365 E5
  • Custom license bundles with competitive pricing
  • A new SKU for Power BI read-only included in Microsoft 365 E3
  • Eliminate Microsoft 365 E3 entirely, and change Microsoft 365 Business to no user limit
  • Make tenant wide license feature activation less confusing
  • Custom search indexes

So, some quite interesting responses indeed, and overall, a wider range of answers than I anticipated.  What, if anything, can we derive from this straw poll? Let’s examine some of the key takeaways.

Privileged Identity Management and Auto Labeling – an Expensive Luxury

Privileged Identity Management (PIM) enables just-in-time and approval-based access to privileged roles within Microsoft 365.  This means that users who require occasional access to elevated roles do not need to have them permanently assigned to their accounts.  They instead activate the roles on-demand for a limited period of time.

The benefits of this are self-evident – the attack surface is reduced when there are less privileged accounts.  Without PIM available, powerful admin roles will inevitably be granted to users and then forgotten about, which creates a potential vulnerability.

Auto labeling with Microsoft Information Protection provides the means to automatically assign a sensitivity label to Microsoft 365 content based on matches to built-in sensitive information types.  This is an important feature as it reduces the burden on the end-user, who oftentimes do not realize when it’s appropriate and important to apply a label to their emails and documents.

So, what would the impact on Microsoft be if these features were included in Microsoft 365 E3?  It’s difficult to speculate, but these are only two features of Microsoft 365 E5. Their inclusion in the more affordable licensing tier would demonstrate that Microsoft is committed to making important security and compliance features accessible to their wider customer base, and not just those who can afford the cost of a Microsoft 365 E5 subscription.

This is also unlikely to significantly affect subscriptions to Microsoft 365 E5.  Many Microsoft 365 E5 features are justifiably included in the premium subscription, and Cloud App Security and Advanced eDiscovery are two good examples of this.  We have also seen recent innovations with Microsoft 365 E5, such as Insider Risk Management and Communication Compliance.  Therefore, it seems there will still be plenty of exclusive features for Microsoft 365 E5 subscribers.

Questions to Consider

An important question that may provide somewhat of an answer to this debate is, “Where should you start with your Microsoft 365 Security and Compliance posture?”  In this article, Microsoft recently provided updated Security and Compliance guidance aimed specifically at the UK public sector.

They separate their Security and Compliance control capabilities into three categories – Good, Better, and Best.  Microsoft recommends “starting with Better“, which does require some Microsoft 365 E5 functionality.

If “Better” is the minimum recommendation for a Security and Compliance posture for Microsoft 365 public sector customers, then there’s also an argument to be made that even the lowest SKUs (e.g., Office 365 E1) should have at least “Good” security controls.

If you’re surveying Microsoft customers, they will of course answer that they would like the most useful parts of Microsoft 365 E5 as part of Microsoft 365 E3. But If “Better” is the recommended and essential starting point from Microsoft, then why sell products that don’t include these key features?

Playing Devil’s Advocate

Whilst this survey clearly shows there is an appetite for more choice when it comes to Microsoft 365 licensing, there are some other perspectives to consider.

For example, if Microsoft Defender for Office 365 were to be included in Microsoft 365 E3, this could lead to protests from third-party vendors from a competition law standpoint. There are many widely adopted third-party security products used with Microsoft 365 and if a premium feature like Defender became more widely accessible, then many customers may be tempted to discontinue such third-party subscriptions.

We should also consider that some of the premium features of Microsoft 365 E5 may have a clear ongoing cost to Microsoft to run, and these couldn’t simply be thrown into Microsoft 365 E3.  This may be the case for Auto-labelling, for example.

Teams Phone System is a difficult one. Customers must bring their own SIP trunk or purchase calling plans.  On that basis, should they also have to purchase Microsoft 365 E5?  There may be ongoing costs to Microsoft for Teams Phone System that justify this, but we can’t say for sure.

That being said – there is one glaring offender within Microsoft 365 E5 that I find impossible to defend.

Teams DLP Does Not Belong in Microsoft 365 E5!

The presence of Data Loss Prevention for Teams within Microsoft 365 E5 only, is baffling to me.  The arguments above on adding PIM, Auto labeling, or any other Microsoft 365 E5 feature to Microsoft 365 E3 can be debated and counter-argued, as can the need for more customization within license SKU’s.

If I’m going to stick my neck out on one opinion though, it’s that I genuinely don’t feel that DLP for Teams is correctly allocated when it comes to licensing.  How can it be fair for DLP to apply to the other key services within Microsoft 365 within the Microsoft 365 E3 subscription, but not the most relevant product in Microsoft’s recent history – Teams? It’s difficult for me to wrap my head around this decision.


Licensing is often a confusing and divisive subject, and at the end of the day, it’s all about opinions – of which there will be many.  Whilst no one could expect Microsoft to “give away the farm,” there is always a balance that can be struck or a compromise to be made.

What is clear is that there’s a common view from customers and partners that unless some of the premium features are added to Microsoft 365 E3, these customers will need to either consider buying Microsoft 365 E5 licenses; uplift current licenses for some or all users; or continue to rely on third-party alternative solutions.

Source Practical365

read more
Exchange Server

Using Filters with the Get-ExoMailbox Cmdlet


Some Complexities to Consider When Upgrading Scripts

Last month, I wrote about upgrading Exchange Online PowerShell scripts to use the Get-ExoMailbox cmdlet instead of its older Get-Mailbox counterpart. One of the reasons I advanced is that Get-ExoMailbox is faster at retrieving mailbox data, which led to some questions about performance in general. It’s easy (and quick) to fetch data for a few mailboxes, but once you need to deal with hundreds or thousands of mailboxes, it’s important to optimize.

Filtering Data

Which brings me to the topic of filters. It’s common to need to process just a few mailboxes of the full set available in a tenant. Filters apply conditions for PowerShell to select the right mailboxes. The better the filter, the faster you get the mailboxes you want.

Filters come in two variants: server-side and client-side. Server-side means that the data coming back from the server is filtered and ready to go. Client-side means that data comes down from the server and is filtered on the client. Generally speaking, for best performance, the golden rule is to use server-side filtering whenever possible.

Server-side filtering happens when the Filter parameter passes a query against mailbox properties to the server. Exchange PowerShell supports a wide range of filterable properties which can be used with its cmdlets. For example, this command returns mailboxes with the Office property set to Dublin.

The equivalent client-side filter fetches all mailboxes and pipes the set to a Where command to filter out the desired mailboxes:

At first glance, you’d expect this code to work because the approach works with Get-Mailbox. But it doesn’t because the Office property is not in the default property set returned by Get-ExoMailbox. Remember, part of the reason why the REST cmdlets are faster than their Remote PowerShell counterparts is the reduction in the number of properties they return. To make our code work, we must tell Get-ExoMailbox to fetch the Office property.

You don’t have to worry about specifying properties when you use server-side filtering because Exchange applies the filter on the server. The property restriction only applies for data returned to the client.

Remember that other parameters cause filtering to happen on the server too. Combining these parameters together creates an even more precise query. In this example, we add the RecipientTypeDetails parameter to instruct Exchange Online to return only user mailboxes:

Specifying the number of objects to be returned is also another form of filter:

The critical point is to be as specific as possible in requesting data from the server. This will speed processing up and mean that you don’t need to discard information when it gets to the client.

Inconsistencies in Filters

A couple of inconsistencies exist in the way that server-side filtering happens for the new cmdlets. For example, you need to be careful with wildcards. Microsoft’s documentation says:

The -like and -notlike operators are limited in using wildcards (*). Specifically, you can only use wildcards at the beginning of a string value, at the end of a string value, or both.

This text makes it seem like you could take a command like this:

And upgrade it to use Get-ExoMailbox instead:

But the command fails with an invalid filter clause, which proves the need for testing even when a statement in Microsoft documentation gives reassurance that something should work.

Reversing Advice

For years, people have applied the golden rule to use server-side filtering to fetch mailbox data. But as we’ve just seen, the REST-based cmdlets do not work in the same way as the older cmdlets. In fact, the Exchange Online development team found that client-side filtering is faster for the new cmdlets, including Get-ExoMailbox. Microsoft says that they’re working on improving server-side filtering for the cmdlets.

After running some tests, it seems like the cause for Microsoft’s assertion is the way that Get-ExoMailbox needs to “warm up” when finding mailboxes. This includes preparing for result pagination, connecting to mailbox servers, and so on. The effect of warming up is easily seen by running the same query multiple times. The first run is always slowest and runs thereafter are much faster, and is easily verified using the Measure-Command cmdlet to run a command several times.

However, with an eye on future performance improvements, I’m not sure that I want to follow Microsoft’s recommendation to use client-side filtering with Get-ExoMailbox. The performance penalty at present doesn’t seem excessive and staying with server-side filtering avoids the need for further change in the future. However, this theory must be tested in the context of individual scripts. For some, it will be best to convert to client-side filtering, for others, the best decision is to stay as is.

Source Practical365

read more
Exchange Server

Microsoft Exchange Server Attacks: Investigation Underway into Potential Leaked PoC Code


Microsoft is investigating the possibility a partner leak may have made the ongoing Microsoft Exchange Server attacks worse. The company says it has observed no internal leaks and is drawing no conclusions about a third-party leak. However, The Wall Street Journal reports an investigation into the potential for a partner leak is ongoing.

Microsoft Exchange Server is in the midst of an attack through an exploit first used by the HAFNIUM group. More threat groups have since targeted the exploit. Microsoft has sent out patches for all versions of the service, including those out of support.

Microsoft says updating Exchange Server is the best way to avoid the exploit. Furthermore, the company has launched a tool to help customers know if they have been breached.

Now the company is said to be investigating if “sensitive information” came from “private disclosures it made with some of its security partners.”

PoC Blunder?

Microsoft is looking to see if the proof-of-concept (PoC) code for the exploit was sent privately between the company and partners of its Microsoft Active Protections Program (Mapp) was leaked. Speaking to ZDNet, the company says it does not believe the leak was internal:

“We are looking at what might have caused the spike of malicious activity and have not yet drawn any conclusions. We have seen no indications of a leak from Microsoft related to this attack.”

Microsoft did send the PoC code to cybersecurity partners on February 23, which was before any patch was released. This was to give those researchers time to detail the exploit. Microsoft says the ongoing attacks bear a resemblance to the internal PoC.

The company is now investigating if a leak happened, how it happened, and whether it was on purpose.

Tip of the day:

Did you know you can use Windows 10´s built in antivirus Microsoft Defender also with scheduled scans? In our tutorial we give you step-by-step instructions on how to program your personal scan-schedule to keep your free of malware.

Source Vanguard

read more
Exchange Server

Old Microsoft Exchange Server Versions Get Patch to Protect Against Ongoing Exploits


The attacks on Microsoft Exchange Server are currently a fluid situation. To help organizations protect themselves from exploits, Microsoft has now issued patches for versions of Exchange Server that are unsupported.

This round of patches follows fixes rolled out for the company for supported versions. Those already with patches are Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019. With the latest round of security fixes, Microsoft is shoring up earlier Exchange versions.

These are versions of the service that had fallen out of support for being too old. That’s a rare move for Microsoft but the gravity of the situation is clear with over 30,000 organizations compromised by the attacks.

By using remote back access attacks against Microsoft Exchange Server, threat actors can access email accounts. 30,000 organizations have already been impacted by the vulnerability. All the critical vulnerabilities are found in Exchange Server 2019, 2016, and 2013. Only Exchange Online has escaped the flaw.

The vulnerabilities are as follows:

  • CVE-2021-26855: CVSS 9.1
  • CVE-2021-26857: CVSS 7.8
  • CVE-2021-26858: CVSS 7.8
  • CVE-2021-27065: CVSS 7.8


Earlier today, we reported the Biden administration has set up a taskforce to monitor the attacks. Microsoft says updating Exchange Server is the best way to avoid the exploit. Furthermore, the company has launched a tool to help customers know if they have been breached.

Security researcher Krebs on Security (Christopher Krebs) says more than 30,000 companies in the U.S. alone have been hit by the attack. He adds most of these organizations are small businesses and governments:

“If your organization runs an [Outlook Web Access] server exposed to the internet, assume compromise between [February 26 and March 3].”

Tip of the day:

If your PC keeps connecting to the wrong WiFi network, you can set WiFi priority to avoid the need to manually select access points over and over again.

Source Winbuzzer

read more
Exchange Server

Switching off legacy authentication for Exchange Online


Keeping legacy authentication enabled in your Microsoft 365 tenant should be avoided; however, going ahead and disabling has traditionally been difficult. Unless you already have a good understanding of your clients, it may present a risk.

Recent improvements to Exchange Online make this simple to configure, and you can now retrieve the information you need to identify potential clients that might be affected.

In this article, we will walk through the process to identify clients using legacy authentication, then utilize the new functionality available to Exchange Online to disable legacy auth for selected protocols.

Reviewing legacy sign-ins to Exchange Online

Before disabling legacy authentication for Exchange Online, it is essential to ensure that clients won’t be affected or prevented from signing in, or if they will, gather enough information so that you can inform people who will be impacted.

You can do this in the Azure Active Directory portal by reviewing sign-in logs using dedicated capabilities to filter based on legacy authentication. To do this, navigate to the Azure AD portal and then select Sign-ins under Monitoring.

Learn more: Introducing Certificate-Based Authentication for Exchange Online Remote PowerShell with Microsoft MVP Vasil Michev

In this section, you will see all sign-in attempts to Azure AD, including sign-in to all Microsoft 365 services from all your clients. We’ll first make sure the information we need is clearly displayed by adjusting the columns displayed by adding client app, as shown below:

client app

Next, we’ll use Add filters to add a filter based on client app:

add filters

The filter for client app will allow us to reduce the list shown to only relevant clients. To do this, expand the filter and from the drop-down list only select the protocols listed under Legacy authentication clients:

Legacy authentication clients

This list is likely to show us both successful and unsuccessful sign-ins. Whilst unsuccessful sign-ins are a concern; we will focus on successful sign-ins to gain insight into what should be real sign-ins from our users. We’ll do this by using Add filters to add a filter based on Status:


We’ll then change the filter for Status to only show results that are a Success:

Status: success

You will then see what may be a long list of sign-ins from legacy authentication clients to Exchange Online. You can expand this using the Date filter to up to one month to gain more insights and use Download to export a list for review.

In the example below, we can see that many users widely use exchange Activesync. Therefore before disabling this protocol, we’ll need to move them to a modern-authentication capable client such as the Outlook App.

Learn more: How to Migrate Exchange Mailbox Permissions with Mike Weaver

If you examine the list and want to understand which legacy authentication protocols are not in active use and can be immediately disabled, then re-open the Client app filter and unselect protocols shown in your results. By unselecting Exchange Activesync, we will be able to see other protocols in active use then easily:

Exchange ActiveSync

We will repeat the process by removing other protocols in active usage until no results are shown. In the example below, we have discovered quickly that only Activesync and Exchange Web Services are in use, and there are no sign-ins over the last month from any other clients.

Exchange ActiveSync and Exchange Web Services

Selectively switching off legacy authentication

After discovering which protocols are not in active use, we are in a position where it becomes low-risk to disable legacy authentication.

Instead of using Exchange Online PowerShell, we can now use the Microsoft 365 admin center to disable legacy authentication for Exchange Online on a protocol-by-protocol basis affecting all users. To do this, navigate to Settings>Org Settings and choose Modern authentication from the services list. In the Modern authentication page, we’ll disable the legacy protocols no longer in use:

Modern authentication

You’ll note in the example above; we’ve disabled legacy authentication for IMAP4, POP3, Exchange Online PowerShell, and Autodiscover. For Exchange Online Powershell, this means you must use either the V2 module or the deprecated V1 module that supports MFA. By disabling legacy authentication to Autodiscover, we will prevent additional legacy clients from attempting to discover Exchange Online information.

Because we know legacy Activesync is in use in our organization and there is a small amount of active legacy Exchange Web Services usage, we’ll leave these protocols enabled.

Once we are happy with the settings, we’ll choose Save to apply these to all Exchange Online clients.

Disabling Legacy Authentication for all Exchange Online services

Using our sign-in log information, we will upgrade or reconfigure discovered clients to use modern authentication. After re-running the steps to filter Azure AD sign-ins and confirming we no longer have any active usage of legacy authentication, we’ll re-visit the Microsoft 365 admin center and disable legacy authentication for all Exchange Online protocols:

Modern authentication options

Further improving security for Microsoft 365 and Exchange Online

Disabling legacy authentication to Exchange Online isn’t the panacea of Microsoft 365 security – it is just one step towards helping keep the environment secure from particular threats, like password spray attacks.

Suppose you have Microsoft 365 E3, Microsoft 365 Business Premium, EMS E3, or Azure AD Premium licenses. In that case, you should consider configuring Conditional Access in your environment to selectively enable Azure Multi-Factor Authentication or configure rules to only allow access to your environment from Intune enrolled devices, Hybrid Azure AD domain-joined PC – or other criteria, such as IP address.

However, suppose you don’t have Conditional Access available. In that case, you may want to consider using Azure AD Security Defaults or (if you need it on a per-user basis) Office 365 multi-factor authentication. Azure AD Security Defaults is particularly useful if you wish to have a guided process over 14 days rather than immediately. It also provides additional MFA protection to privileged administrative actions in your tenant.

Source Practical365

read more
Exchange Server

Exchange Retention and Communication Compliance Updates


While we are eagerly awaiting the usual storm of announcements during Ignite week, some minor but essential releases have been completed over the past few weeks. So, let’s spend the next few minutes covering them in some detail.

Exchange Online support for “when labeled” retention

First, let’s briefly talk about the feature announced as part of Message Center post MC216379, namely the fact that Exchange Online now supports retention based on the date the label was stamped on an item.

Traditionally, Exchange’s retention policies have always acted based on the date the item was created or received, with some exceptions as detailed in the official documentation. When Office 365 introduced the new-style retention labels/policies, they offered some novel options, such as the ability to calculate the retention age based on the date the item was last modified or the label was stamped on it. A more advanced option that allowed organizations to configure event-based retention was released later on. Up until now, however, Exchange Online only supported the “traditional” when created approach.

In June, Microsoft announced that they’ve started rolling out an update through the service to allow this additional retention option to work against items stored in Exchange Online mailboxes. To make this possible, the Managed Folder Assistant has been patched to process items with the “stamp date” in mind.

Therefore, admins need to complete no additional actions to enable this functionality. However, you can verify that it’s working as expected by creating a retention label with the when it was labeled setting, then check whether the corresponding items are retained or deleted within the expected timeframe, based on the date the label was stamped on them. Don’t forget that the MFA in Exchange Online runs on a seven-day work cycle, so you can expect some delay here.

So how do we go about checking this new functionality? First, head over to the Security and Compliance Center or the new Compliance Center and create a retention label when it was labeled option configured, as shown on the screenshot below.

Next, publish the policy to some or all mailboxes and wait for the complete distribution process. Then you have to wait some more for Exchange’s Managed Folder Assistant to reprocess the mailbox and make the new labels/tags available. As those are “new style” retention tags, you will not find them under OWA -> Options -> Mail -> Retention policies. Nevertheless, they will become available once the mailbox has been processed.

Exchange when applied

When this happens, you will see the newly created Exchange when applied tag available in the right-click menu in OWA and/or Outlook. All you need to do then is to assign the tag to some item and wait for it to be processed. Since we want to test the when it was labeled setting, it makes sense to tag an older item with it, such for which the when created scenario would cause the item to expire immediately. If the new label works as expected, the item should remain available for three days after being tagged, give or take. Of course, you can also tag some other items to use as a control group. In my scenario, three different items were stamped with the Exchange when applied tag/label, one received (created) a minute ago, one created a week ago, and one even older.

Even though I’m running a somewhat older version of Outlook (semi-annual targeted channel, so version 2002 at the time of writing this post), the new label and corresponding expiration period are displayed correctly in the client, as shown on the screenshot below (left-hand side). OWA might not reflect the expiry date correctly initially (right-hand side). Even though the correct label information is displayed on the info tip (top of the message screen), the expiration date is shown as Never, which should not be the case given the label is configured with three-day retention period. After a relog or two, the correct date is eventually displayed.

As expected, after the retention period has expired, the three tagged messages were deleted and are currently residing in the RecoverableItems subtree (see screenshot below). The items were received (created) at different times, so their “creation” dates differ, and if we were using the old-style labels/tags, they would have been removed at different times. Since the newly created label is configured with the “when labeled” setting though, and all items were stamped at the same time, they were all processed at the same time too, which is precisely the behavior we would expect.

In a nutshell, this is how the recently introduced new option for retention labels work in Exchange Online. While this might seem like a minor change and very straightforward to implement, the important thing to note here is that Microsoft is bridging the gap between how different workloads handle retention labels, and we are now one step closer to a truly “unified” retention experience.

New Communication Compliance features

The other exciting news we’ll cover is around a few recent releases, either as previews or in GA, within the Communication compliance feature set. Let’s start with the newly introduced granular roles. Back when the Communication Compliance solution was intially launched, granting access to it was a somewhat convoluted process, as it required access to multiple different roles, which at the time were not combined into any of the default Role Groups. Microsoft has addressed this as part of Roadmap item #61068, which just finished rolling out across the service.

While we’d expect the new roles (and role groups) to be available from within the Compliance Center, where the Communication Compliance solution lives, this is not the case. Even two years after the launch of the new standalone Compliance and Security portals, the experience within those remains very limited when it comes to managing permissions, so for any permission-related tasks, you should head to the good old Security and Compliance Center.

On-Demand Webinar: Introducing Certificate-Based for Exchange Online PowerShell

Once there, you will find a total of five Role Groups related to Communication Compliance, as showcased on the screenshot below. Each of these Role Groups contains one or more Roles, correlating to the different tasks you can perform as part of the feature, with the Communication Compliance Role Group having the widest set of permissions assigned.

The set of individual roles are depicted below. Exploring them via PowerShell has the added benefit of surfacing their descriptions, which the devs have neglected to expose in the UI. Apart from the roles shown below, the Data Classification Feedback Provider role, used to provide feedback to the trainable classifiers, is added as part of the Communication Compliance Admins (shown only as Communication Compliance in the UI) Role Group.

Thanks to the new granular roles, we now have an easier separation between investigators (who can see the full message content), analysts (can only see metadata), viewers (access to reports only) and so on. You can find additional notes about the new roles and recommendations of which role to use to find scenarios in the official documentation.

Apart from the role improvements mentioned above, we now can anonymize user names within policy matches. You can toggle the corresponding setting by navigating to the Communication Compliance tab, hitting the Communication Compliance settings button on top, and landing on the Privacy page. The configuration itself is self-explanatory, as shown below:

Another recently launched improvement is the ability to detect repeated behavior over time, as detailed in Roadmap item #61067. Yet another useful feature is the ability to detect adult, racy and gory content as part of images exchanged between participants (Roadmap item #64189). Some caveats apply: the image must be between 50KB and 4MB in size, its dimensions must be greater than 50×50 pixels, and must be either a JPEG, GIF, BMP or PNG format.

The last feature we want to mention is the ability to Remove Teams messages (Roadmap item #66100) and replace them with a generic policy tip, indicating a violation. This functionality applies to Teams chats and channel messages, including those sent to private channels.

So how about testing all these? After updating my policies to include the new adult/racy/gory classifiers, I added some NSFW content in private chat and a team. The good news is that two out of the three images I inserted were flagged as violations, which is a good outcome, considering I didn’t bother to check whether they are within the accepted ranges for size/dimensions. The bad news is that the review experience currently has some issues and makes it impossible to see what content the  message was flagged for.

Not only the built-in viewer failed to display the images, but downloading the original resulted in only getting a zip file with a single summary.txt item, which contains just the below error:

Doc_Num              Doc_ID   Custodian              SubjectOrTitle       File_Name             File_Type               Error_Message

1              9543875d71744ef4a42f2cc609ff466dd0dbff433771a0b39eaffb08569076e9                      0-weu-d1-ea6ae215cd9093dabf2e5fd6e6d1c9f4.jpg                    jpg          The remote server returned an error: (404) Not Found.

This issue seems to be around the review UI, opening the underlying Supervisory mailbox in OWA, and reviewing the content there works as expected. Hopefully, the observed behavior was a temporary fluke or the result of an incomplete feature rollout.

On the positive side, the user was flagged immediately as a repeat offender, and the Remove messages from Teams functionality executed immediately and flawlessly. The screenshot below shows the experience of removing the messages via the Review UI and what the end user sees within the Teams client.

In summary, we’ve received some useful improvements to the Communication Compliance solution, both in terms of making sure the right people can see just the correct data and the overall review experience.

Source Practical365

read more
Exchange Server

Microsoft Authenticator on Android Finally Gets Ability to Change Passwords


Microsoft Authenticator for Android is receiving an update to add a much-requested new feature to the tool. Specifically, users can now change their passwords directly in the application. Android users have been waiting a long time for this ability.

Microsoft brought the feature to its Authenticator app on iOS earlier this year. At the time, the company promised it would also come to the Android variant. After a longer than expected delay, the feature is available.

For users who leverage two-factor authentication (2FA) on Microsoft 365, this is a welcome addition. When using the Microsoft Authenticator app, more information about accounts is visible. For example, the phone sing-in tool is shown. This is a one-time password issued by Microsoft. The cost can be used for a single authentication.

Also directly in the app, users can now update security information for accounts, including change the password.

“As part of our commitment to continually improve our customer experiences, we revamped the UX of how accounts are represented in the Microsoft Authenticator app. We heard from customers that staying informed about your account security should be simple and seamless, and we’ve been listening,” the company explained in March.

Available Now

Microsoft launched its Authenticator app back in 2016. The service provides native two-factor authentication on devices when accessing a Microsoft Account. Since the launch, numerous features have been added, including a phone sign-in ability, fingerprint support, password free login, and Apple Watch support.

To use the new password feature, users must be running the latest version of Microsoft Authenticator. If you’re new to the app, you can download if from the Google Play Store here.

Source Winbuzzer

read more
Exchange Server

Windows 10: How to Uninstall the Microsoft Store (aka Windows Store)


Windows 10 ships with plenty of universal apps, which are native to the platform. Some users may not need Universal Windows Platform (UWP) apps and want to remove them. We already showed you how to remove unwanted bloatware apps on Windows. However, what if you want to remove the Windows Store entirely? In this guide we will show you how uninstall Windows 10 apps using PowerShell.

While Microsoft’s Windows 10 native apps are not bloatware in the strictest sense, they are often pre-installed, and some users don’t want them. Luckily, Microsoft allows you to remove Windows 10 Bloatware easily.  If you want to remove the Microsoft Store, it’s not quite as simple.

Microsoft obviously doesn’t want Windows 10 users removing its app store. As such, this app can’t be removed completely, but you can hide it by using PowerShell. The method also works to block Windows Store apps.

It is worth noting that the Windows Store is called the Microsoft Store these days, although the rebranding is unimportant to functionality. The store remains ingrained in Windows 10 and you can use it to download UWP apps.

The Microsoft Store is primarily used to manage the relatively new “Universal Windows Platform Apps” (UWP apps). Similar to the Apple App Store or the Google Play Store for Android, you can add free and commercial apps to Windows at the push of a button.

However, many users prefer the traditional method of downloading desktop applications and don’t use the Store. If you are one of those users, we will show you how to uninstall Windows 10s app store. We will also explain how to reinstall the Windows Store whenever you want.

How to Remove the Microsoft Store app in Windows 10

First you open the PowerShell as administrator via the Start context menu that can be reached with the key combination “Windows + X“.

Windows 10 - Run Windows PowerShell as Admin
Windows 10 – Run Windows PowerShell as Admin

Then enter the following command in the PowerShell window, which will automatically uninstall the Microsoft Store app:

Windows 10 - PowerShell - Uninstall Microsoft Store
Windows 10 – PowerShell – Uninstall Microsoft Store

Reinstall Windows Store and other pre-installed apps

To restore the Microsoft Store if necessary, the following command in the PowerShell is sufficient:

Get-AppxPackage-AllUsers|Foreach{Add-AppxPackage-DisableDevelopmentMode-Register“$($ _. InstallLocation)\AppXManifest.xml”}

In addition to the store app, this also brings back all other pre-installed Windows 10 apps. You can then easily uninstall other unwanted apps with a click of the mouse.

Windows 10 - PowerShell - Restore Preinstalled Apps
Windows 10 – PowerShell – Restore Preinstalled Apps

Source Winbuzzer

read more
Exchange Server

Microsoft Edge 81 Launches on Stable Channel, Bringing Collections to All


After a short Covid-19 related delay, Microsoft Edge 81 is available on the stable channel. The update holds features an improvements the beta channel has been testing since February, with Collections the stand out addition.

For the unfamiliar, Collections is essentially Microsoft’s answer to extensions like Pocket. You can drag and drop any text, page, or image into an organized sidebar, while also adding supplementary notes. Once finished, you access it through the browser or export it to Word or Excel and get working. They sync across all devices so you can access an online shopping list on your phone when you’re out and about, for example.

The idea is for Collections to appeal to just about anyone, but if you don’t the icon in your browser bar Microsoft has introduced the ability to hide it with this build. It has also rolled out a host of improvements to the browser, with the most interesting listed below:

  • “Application Guard. Extensions support now available in the container.
  • The F12 Dev tools are localized in 10 new languages, so they will match the language used in the rest of the browser.
  • Added support for Dolby Vision playback. On Dolby Vision-enabled Windows 10 Build 17134 (April 2018 Update), websites can show Dolby vision content.
  • Microsoft Edge can now identify and remove duplicate favorites and merge folders with the same name. To access the tool, click the star on the browser’s toolbar and select “Remove duplicate favorites”. You can that confirm changes and any updates to your favorites will be synced across devices.
  • The new solid InPrivate blue pill in the top right corner helps reassure users they are browsing InPrivate.
  • Open external links in the correct browser profile. Select a default profile for links opened for external apps to open in from edge://settings/multiProfileSettings.
  • Added a warning that alerts users who sign into a browser profile with an account after being previously signed in with another account. This warning will help prevent unintentional data merging.
  • If you have payment cards saved in your Microsoft account, you can use them in Microsoft Edge while filling out payment forms. The cards in your Microsoft account will sync across desktop devices and the full details will be shared with the website after two-factor authentication (CVC code and your Microsoft identity.) For further convenience, you can choose to securely save a copy of the card on the device during authentication.
  • Line Focus is designed for users who like to focus on a limited part of the content as they read. It lets users keep the focus on one, three, or five lines at a time and dims out the rest of the page to let users read without distraction. Users can scroll using touch or arrow keys and the focus shifts accordingly.
  • Microsoft Edge is now integrated with Windows Speller on Windows platforms 8.1 and above. This integration provides greater language support, with access to more language dictionaries and the ability to use Windows custom dictionaries.
  • When PDF documents are opened using Microsoft Edge, users will now be able to create highlights, change color, and delete highlights.”

Considering the global pandemic, there’s a lot to be enjoyed here. The improvements touch most major aspects and bring back some Edge HMTL favorites like extended PDF support. You can read the full list of additions in the official documentation.

Source Winbuzzer

read more
1 2
Page 1 of 2