How to block external access to Exchange 2019 via Client Access Rules?

[Update]: This post was updated on May 08, 2020.

One of the most interesting security options in Exchange 2019 is the Client Access Rules feature. It allows the admin to define rules to block or restrict access to EAC (formerly ECP) ​​and EMS (Exchange Management Shell). This functionality was not present in previous versions of Exchange and is now a security milestone for small organizations that cannot afford solutions such as firewalls that work at OSI layer 7 (application layer) to restrict access from outside the organization.

The purpose of client access rules

Management of client access rules is only possible at the Exchange Management Shell level. There is no GUI you can use to manage them. With the Client Access Rules feature, you can block:

  • Individual IP addresses, e.g.
  • Ranges of IP addresses, e.g. –
  • Subnet IP, e.g. 168.0.0/24

Using advanced rules, you can also control items such as authentication protocols, selected users in Active Directory, or users with specific attributes in AD such as e.g. B. Block department, company, etc. (the last option seems to be reserved for Exchange Online, for the moment). For more information about client access rules, see this Microsoft document.

The elements of the client access rules

A single client access rule consists of the following elements:

  • Condition – identifies the client connection to which the rule applies.
  • exception – identifies the client connection to which the rule should not apply.
  • action – Defines what action to take when the client connection meets the condition.
  • priority – defines the order in which rules are executed. Each rule is assigned a priority number. The lower the number, the higher the priority. By default, the oldest rules have the highest priority, so they are processed first.

The Client Access Rules cmdlets

Various cmdlets are available to manage client access rules. See the following list:

  • Get-ClientAccessRule – This cmdlet returns the results showing a list of the currently configured rules.
  • New-ClientAccessRule –Use this cmdlet to create new rules.
  • Set-ClientAccessRule – Use this cmdlet to modify existing rules.
  • Test-ClientAccessRule – A useful cmdlet that you can use to test a rule configuration.
  • Remove-ClientAccessRule – Use it to remove rules.

How to block access to EAC (ECP)

You can use client access rules to block access to the Exchange admin center. In my example below I want to block access for all users except for one internal network, VLAN, which is management. This prevents other subnets within the organization and users from outside the organization from accessing the Exchange admin center. The main purpose is to keep the organization safe and secure from unauthorized access.

A good place to start is to run the following cmdlet:

New-ClientAccessRule -Name “Always Allow Remote PowerShell” -Action AllowAccess -AnyOfProtocols RemotePowerShell -Priority 1

This command prevents the Exchange Management Shell (EMS) from being truncated if the administrator makes a mistake during configuration.

Block access for all users except one network

To block access to EAC for all users except the respective network, e.g. B. in my case VLAN Management, run the cmdlet as follows:

New-ClientAccessRule -Name „Allow ECP only for VLAN MGMT” -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -ExceptAnyOfClientIPAddressesOrRanges -Priority 2

Block access for all users except one

Consequently, only VLAN management can access EAC. Users from other VLANs/subnets are not allowed to access EAC.

Review a list of client access rules

Run the following cmdlet to review a list of configured rules:


Review a list of client access rules

Results are returned where you can see details about each rule such as name or priority in the list.

Verify that the rule is working properly

To test the rule to verify that it works as expected, try logging into EAC from a different network than in my case. If the rule is working properly, you should see something similar to:

Verify that the rule is working properly

You can also run the above cmdlet to test the rule Test-ClientAccessRule. This simulates the connection e.g. B. from the IP address to EAC for the administrator user:

Verify that the rule is working properly

Of course, this is just one example of how you can use cmdlets to manage a variety of functionality offered by Client Access Rules. Now let’s look at how to block access to EAC using various Active Directory attributes.

Block access to EAC based on the user’s Active Directory attributes

[Important] At the time of writing this article, this method worked flawlessly. However, a recent test revealed that -UserRecipientFilter is no longer available in Exchange 2019. This Docs article seems to confirm this information. The New-ClientAccessRule cmdlet with this filter runs successfully and returns no errors. However, access is not blocked afterwards. Running this cmdlet in Exchange Online works without any issues.

Suppose your corporate security policy requires that only IT staff have access to the Exchange admin center. To make this case even more complex, let’s also assume that the IT department is located in different parts of the world and that there are different networks to consider (LAN, VLAN, etc.), which is really problematic, rules based on IP to write addresses).

For example, to meet the above requirements, you can create the client access rules based on the department Attribute in Active Directory. I created two new employees in AD who are members of the IT department and gave them organization management rights.

Department attribute in AD

Before starting a new rule configuration, I remove the rule based on the IP subnet using the following cmdlet:


Remove the client access rule

Now I can create a new rule that checks the value of the Department AD attribute. If the value is different from “IT”, access is denied. This is the command:

New-ClientAccessRule -Name „Allow access to ECP only for IT” -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -UserRecipientFilter {Department -ne “IT”} -Priority 2

New client access rule

Now it’s time to test the new rule. I will be using a newly created account by Jon Snow to access EAC (Jon is a member of the IT team). For this purpose I run this cmdlet:

Test client access rule.

If no results are returned, it means the user is not subject to client access rules. And that’s correct because I configured a blocking rule. Now let’s test what happens when I change the value of the Department attribute to “HR”.

AD properties of a user.

To check the results of the rule, I use the same cmdlet as for the example above:

Test the client access rule results.

You can see that the client access rule works correctly after I change the value of the Active Directory attribute by blocking access to ECP.

Here’s what it looks like from the browser (for Jon Snow when he’s in the “HR” department):

A notification about blocked access to EAC.

And here’s an example for another user, Tyrion Lannister, coming from the “IT” department. As you can see the user has access to ECP:

Access to EAC

bottom line

These examples are just a small portion of what you can really get out of Client Access Rules functionality in Exchange 2019. The list of scenarios that you can cover with this feature is almost endless and will definitely help you meet the strict security requirements in your Exchange 2019 environment.

See also:

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *