Exchange Client Access Rules

Recently I was asked to limit access to the client-facing portions of Exchange online, mainly Outlook for Web, Outlook desktop clients (both Windows and macOS), POP/IMAP, and ActiveSync apps. Basically, this organization only wanted enough access to Exchange to allow Teams voicemail to function, and voicemail to show up in the Microsoft Teams client. The organization hosts their email with another provider, but they’re using Microsoft Teams for calling.

While these methods are probably too much for most organizations, they can serve as a starting point for limiting points of access that you do not want.

Prerequisites 

Creating Exchange client access rules can only be done via PowerShell. To do this, you need the Exchange Online PowerShell module. To install this module on your computer, open PowerShell as an administrator and run this command:

Install-Module -Name ExchangeOnlineManagement

Once the module is installed, you can connect to your environment by running this command and signing in. You should sign-in as a user with the Exchange Administrator role in Azure AD.

Connect-ExchangeOnline

Create Client Access Rule

There is one need-to-know item with client access rules – they take time to apply. Microsoft states that the first rule you create in your environment may take up to 24 hours to apply. In my environment, it didn’t take the full 24 hours, but it did take overnight. After the first rule is created and applies, additional rules, changes to existing rules, or deleting rules may take up to one hour to apply. I was consistently seeing changes take the full one hour.

First, it’s best practice to create a rule with the highest priority (priority 1) that maintains access to the Exchange Admin Center and access via PowerShell. This will make sure that you do not lock yourself out of your environment. To create this rule, run this command.

New-ClientAccessRule -Name "AllowAdminAccess" -Action Allow -AnyOfProtocols RemotePowerShell,ExchangeAdminCenter  -Priority 1

Next, we can create the actual rule to block access to the Exchange protocols. As of this writing, these are the available protocols to block (source: New-ClientAccessRule (ExchangePowerShell) | Microsoft Docs).

  • ExchangeActiveSync
  • ExchangeAdminCenter
  • ExchangeWebServices
  • IMAP4
  • OfflineAddressBook
  • OutlookAnywhere
  • OutlookWebApp
  • POP3
  • PowerShellWebServices
  • RemotePowerShell
  • REST
  • UniversalOutlook (Mail and Calendar app)

There are two ways to block protocols. You can use the AnyOfProtocols parameter, or the ExceptAnyOfProtocols parameter. Any will block the protocols you specify, Except will keep open the protocols you specify. In my case, I was blocking everything except what was required for Teams voicemail, so I used except and kept REST enabled (which is how Teams voicemail gets to the Teams client).

Here is my command to keep open REST, while disabling everything else:

New-ClientAccessRule -Name "BlockClientAccess" -Action DenyAccess -ExceptAnyOfProtocols REST -Priority 2

Once created, you can use this command to view your client access rules.

Get-ClientAccessRule | Format-List

Mobile Apps

Mobile apps created by Microsoft like Outlook on iOS and Android do not adhere to client access rules (source: Client Access Rules in Exchange Online | Microsoft Docs, under Important Notes > Client Access Rules and middle-tier applications). So, to block these, you must use an ActiveSync access rule.

To block Outlook from connecting on iOS and Android, run this command:

New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "Outlook" -AccessLevel Block

That is it. Hopefully this post can help you craft your rules to keep your Exchange environment secure.

Disclaimer

All content provided on this blog is for information purposes only. Windows Management Experts, Inc makes no representation as to accuracy or completeness of any information on this site. Windows Management Experts, Inc will not be liable for any errors or omission in this information nor for the availability of this information. It is highly recommended that you consult one of our technical consultants, should you need any further assistance.

Share:

Facebook
Twitter
LinkedIn

Contact Us

=
On Key

More Posts

WME Security Briefing 27 May 2024

Kinsing Hacker Group Exploits Docker Vulnerabilities Overview Recent investigations have shown that the hacker group Kinsing is actively exploiting Docker vulnerabilities to gain unauthorized access to systems. The modified hacker group targets misconfigured Docker API ports deployed with cryptocurrency mining malware.

Read More »
WME Cybersecurity Briefings No. 010
Cyber Security

WME Security Briefing 20 May 2024

Advanced Persistent Threats: North Korean Hackers Launch Golang Malware Overview A new malware strain, called Titan Stealer, is currently actively circulating in the threat landscape, targeting a variety of personal data and linked to North Korean state-sponsored cyber espionage

Read More »
WME Cybersecurity Briefings No. 009
Cyber Security

WME Security Briefing 08 May 2024

Exploitable vulnerability in Microsoft Internet Explorer, used to deploy VBA Malware Overview Cybersecurity researchers discovered a severe exploitation targeting a bug that had already been patched in the Microsoft Internet Explorer browser. Their report added that

Read More »
Be assured of everything

Get WME Services

Stay ahead of the competition with our Professional IT offerings.

=